Zigbee 3.0 Overview

Introduction

Purpose

This document describes basic concepts of Zigbee mesh networks. This is a Zigbee PRO 2023 (R23) certified stack for the Zigbee and Zigbee PRO stack profiles. For a more complete Zigbee 3.0™ Release description along with stack settings pertaining to Texas Instruments devices, please refer to the ZBOSS User’s Guide.

Definitions, Abbreviations and Acronyms

Term	Definition
AF	Application Framework
AES	Advanced Encryption Standard
AIB	APS Information Base
API	Application Programming Interface
APS	Application Support Sub-Layer
APSDE	APS Date Entity
APSME	APS Management Entity
BDB	Base Device Behavior
CCM*	Enhanced counter with CBC-MAC mode of operation
EPID	Extended PAN ID
GP	Green Power
GPD	Green Power Device
MSG	Message
MT	Zigbee’s Monitor and Test Layer
NIB	Network Information Base
NWK	Network
OTA	Over-the-Air
PAN	Personal Area Network
RSSI	Received Signal Strength Indication
TC	Trust Center
TCLK	Trust Center Link Key
ZCL	Zigbee Cluster Library
ZDO	Zigbee Device Object
ZC	Zigbee Coordinator
ZR	Zigbee Router
ZED	Zigbee End Device

Reference Documents

1. Zigbee document 05-3474-22 Zigbee PRO 2023 (R23) Specification

2. Zigbee document 07-5123-08 Zigbee Cluster Library 8 Specification

3. Zigbee document 13-0402-13 Zigbee Base Device Behavior

4. Zigbee document 14-0563-16 Zigbee Green Power specification

All documentation can be located on the Connectivity Standards Alliance website.

Zigbee

A Zigbee network is a multi-hop network of mains-powered or battery-powered devices. This means that successful communication between two devices may require intermediate devices to relay messages. Due to the cooperative nature of the network, each device is required to perform specific networking functions and configure certain parameters to specific values. The role of a device is determined by the set of networking functions it performs and is called the logical device type. The set of parameters that need to be configured to specific values, along with those values, is called the stack profile.

Logical Device Types

The three logical device types in a Zigbee network are Coordinator, Router, and End Device. A Zigbee network consists of a device with network formation capabilities (such as Coordinator or Router) and multiple Router and End Device nodes. Note that the device type does not in any way restrict the type of application that may run on the particular device.

Figure 22. Example of typical Zigbee network

Example of typical Zigbee network shows a typical Zigbee network with the Zigbee Coordinator (black), the Routers (red), and the End Devices (white).

An application can be defined as any of these three logical devices depending on the configuration flags enabled in the project.

Logical Device	Compilation flags needed
Coordinator	ZB_COORDINATOR_ROLE
Router	ZB_ROUTER_ROLE
End Device	ZB_ED_ROLE

Coordinator

A coordinator is a device with network formation capabilities, but without network joining capabilities. This means the device can only create its own network, but not join existing networks. To create a network, the coordinator node scans the RF environment for existing networks, chooses a channel and a network identifier (also called PAN ID) and then starts the network. In Zigbee 3.0 this device creates a Centralized security network and is mandated to behave as the Trust Center of this network, which means that this device is responsible for managing security of the network and is the only device capable of distributing keys and allowing devices to join the network it has created.

The coordinator node can also be used, optionally, to assist in setting up application-level bindings in the network.

The role of the coordinator is mainly related to starting the network and managing the keys. Besides that, it behaves like a router device. Note that the Coordinator must handle the network procedures related to devices joining or leaving the network, so it cannot be absent of its own network. Further details on security schema are available in z-stack-overview-security.

Router

A router performs functions for allowing other devices to join the network, for multi-hop routing, and for assisting its child end devices with communication. In Zigbee 3.0 this device has been granted with formation capabilities that allow it to create a Distributed security network. This formation capability allows the router device to create a network that does not have a security manager. This means that once the network has been created, the router which created it does not have any special role in this network. More details are available in z-stack-overview-security.

In general, Routers are expected to be active all the time and thus have to be mains-powered.

End Device

An end device has no specific responsibility for maintaining the network infrastructure, so it can sleep and wake up as it chooses. This device can be a battery-powered node. Generally, the memory requirements (especially RAM requirements) are lower for an end device.

Note

In Zigbee 3.0 all sample application projects are provided with the needed pre-include files to build each device type according to the project.

Stack Layers

The following is a brief description of the various Zigbee 3.0 layers and their purpose towards Zigbee functionality. Note that Zigbee is built on top of the IEEE 802.15.4 2006 radio specification.

• IEEE 802.15.4 PHY: The radio’s physical and electrical characteristics

• IEEE 802.15.4 MAC: Responsible for sending and receiving RF Frames

• Zigbee-PRO NWK: Handles packets within the confines of a Zigbee network

• Zigbee-PRO APS: Determines now packets are interpreted by the Zigbee application

• Zigbee Devices: Commonly referred to as ZDO, this defines how the local device operates within a Zigbee network

• Base Device Behavior: Standard for commissioning a device in Zigbee network

• Manufacturers Application: Including the Zigbee Cluster Library (ZCL), this contains the attributes and clusters which define the Zigbee device’s purpose, behavior, and usage within the network.

Figure 23. Zigbee Software Architecture

The Zigbee PRO 2023 Compliant Platform layers are pre-built for CC23xx Zigbee 3.0 devices and require no modification. Zigbee 3.0 Base Device & Clusters layers can be further configured and determined by the developer.

Stack Profile

The set of stack parameters that need to be configured to specific values, along with the above device type values, is called a stack profile. The parameters that comprise the stack profile are defined by the Connectivity Standards Alliance.

All devices in a network must conform to the same stack profile (i.e., all devices must have the stack profile parameters configured to the same values).

If application developers choose to change the settings for any of these parameters, they can do so with the caveat that those devices will no longer be able to interoperate with devices from other vendors that choose to follow the Zigbee specified stack profile. Thus, developers of “closed networks” may choose to change the settings of the stack profile variables. These stack profiles are called “network-specific” stack profiles.

The stack profile identifier that a device conforms to is present in the beacon transmitted by that device. This enables a device to determine the stack profile of a network before joining to it. The “network-specific” stack profile has an ID of 0, the legacy Zigbee stack profile has ID of 1, and the Zigbee PRO stack profile (which is used for Zigbee 3.0) has ID of 2. The stack profile is configured by the ZB_STACK_PROFILE parameter in the zb_config.h file. The stack profile ID of 3 is reserved for Green Power devices, and it appears in the respective frames.

Addressing

Address Types

Zigbee devices have two types of addresses. A 64-bit IEEE address (also called MAC address or Extended address) and a 16-bit network address (also called logical address or short address).

The 64-bit address is a globally unique address and is assigned to the device for its lifetime. It is usually set by the manufacturer or during installation. These addresses are maintained and allocated by the IEEE. More information on how to acquire a block of these addresses is available at IEEE Registration Authority.

The 16-bit address is assigned to a device when it joins a network. Within that network, it is unique and used for identifying devices and sending data.

Network Address Assignment

Stochastic Addressing

Zigbee PRO uses a stochastic (random) addressing scheme for assigning the network addresses. This addressing scheme randomly assigns short addresses to new devices, and then uses the rest of the devices in the network to ensure there are no duplicate addresses. When a device joins, it receives its randomly generated address from its parent. The new network node then generates a “Device Announce” frame (which contains its new short address and its extended address) to the rest of the network. If there is another device with the same short address, a router node in the network will send out a broadcast “Network Status – Address Conflict” to the entire network and all devices with the conflicting short address will change its short address. When the conflicted devices change their address, they issue their own “Device Announce” to check their new address for conflicts within the network.

End devices do not participate in the “Address Conflict”. Their parents do that for them. If an “Address Conflict” occurs for an end device, its parent will issue the end device a “Rejoin Response” message to change the end device’s short address and the end device issues a “Device Announce” to check their new address for conflicts within the network.

When a “Device Announce” is received, the association and binding tables are updated with the new short address, but routing table information is not updated (new routes must be established). If a parent determines that the “Device Announce” pertains to one of its end device children, but it didn’t come directly from the child, the parent will assume that the child moved to another parent.

Addressing in Zigbee 3.0

In order to send data to a device on the Zigbee network, the application must determine a destination address. In addition to the address itself, the address mode parameter also needs to be specified. The destination address mode can take one of the following values (defined in zboss_api_aps.h):

/**
* @name APS addressing mode constants
* @anchor aps_addr_mode
*/
/** @{ */
#define ZB_APS_ADDR_MODE_DST_ADDR_ENDP_NOT_PRESENT  0x00U /*!< DstAddress and DstEndpoint not present  */
#define ZB_APS_ADDR_MODE_16_GROUP_ENDP_NOT_PRESENT  0x01U /*!< 16-bit group address for DstAddress; DstEndpoint not present */
#define ZB_APS_ADDR_MODE_16_ENDP_PRESENT            0x02U /*!< 16-bit address for DstAddress and DstEndpoint present */
#define ZB_APS_ADDR_MODE_64_ENDP_PRESENT            0x03U /*!< 64-bit extended address for DstAddress and DstEndpoint present  */
#define ZB_APS_ADDR_MODE_BIND_TBL_ID                0x04U /*!< "destination endpoint" is interpreted as an index in the binding table,
                                                            all other destination address information is ignored */

The address mode parameter is necessary because, in Zigbee, packets can be unicast, multicast, or broadcast. A unicast packet is sent to a single device, a multicast packet is destined to a group of devices and a broadcast packet is generally sent to all devices in the network. An indirect packet is used when the application does not explicitly know the destination of the packet. This is explained in more detail below.

Unicast

This is the normal addressing mode and is used to send a packet to a single device whose network address is known. The address mde is set to ZB_APS_ADDR_MODE_16_ENDP_PRESENT and the destination network address is carried in the packet.

Indirect

This is when the application is not aware of the final destination of the packet. The mode is set to ZB_APS_ADDR_MODE_DST_ADDR_ENDP_NOT_PRESENT and the destination address is not specified. Instead, the destination is looked up from a binding table that resides in the stack of the sending device. This feature is called Source binding (see Binding).

When the packet is sent down to the stack, the destination address and end point is looked up from the binding table and used. The packet is then treated as a regular unicast packet. If more than one destination device is found in the binding table, a copy of the packet is sent to each of them. If no binding entry is found, the packet will not be sent.

Broadcast

This address mode is used when the application wants to send a packet to all devices in the network. The address mode is set to ZB_APS_ADDR_MODE_16_ENDP_PRESENT and the destination address can be set to one of the following broadcastaddresses:

0xFFFF – the message will be sent to all devices in the network (includes sleeping devices). For sleeping devices, the message is held at its parent until the sleeping device polls for it or the message is timed out (NWK_INDIRECT_MSG_TIMEOUT in ti_zstack_config.h, as generated from the project’s .syscfg file RF STACKS → Z-Stack → Advanced → Routing).

0xFFFD – the message will be sent to all devices that have the receiver on when idle (RXONWHENIDLE), that is, all non-sleepy devices.

0xFFFC – the message is sent to all routers (including the coordinator).

Group Addressing

This address mode is used when the application wants to send a packet to a group of devices. The address mode is set to ZB_APS_ADDR_MODE_16_GROUP_ENDP_NOT_PRESENT and the address parameter must be set set with the group identifier.

Note that groups can also be used in conjunction with indirect addressing. The destination address found in the binding table can be either a unicast or a group address. Also note that broadcast addressing is simply a special case of group addressing where the groups are set up ahead of time and defined by Connectivity Standards Alliance.

Important Device Addresses

An application may want to know the address of a device (local). Use the following functions to get the addresses.

• MAC_PIB().mac_short_address – Retrieve the short address.

• MAC_PIB().mac_extended_address – Retrieve the IEEE address.

Binding

Binding is a mechanism to control the flow of messages from one application to another application (or multiple applications). The binding mechanism is implemented in all devices and is called source binding.

Binding allows an application to send a packet without knowing the destination address, the APS layer determines the destination address from its binding table, and then forwards the message to the destination application (or multiple applications) or group.

Building a Binding Table

There are 3 ways to build a binding table:

• Zigbee Device Object Bind Request – a commissioning tool can tell the device to make a binding record.

• Zigbee Device Object End Device Bind Request – 2 devices can tell the coordinator that they would like to setup a binding table record. The coordinator will make the match up and create the binding table entries in the 2 devices.

• Finding and Binding commissioning process for initiator devices.

Zigbee Device Object Bind Request

Any device or application can send a ZDO message to another device (over the air) to build a binding record for that other device in the network. This is called Assisted Binding and it will create a binding entry for the sending device.

The Commissioning Application

An application can create a bind between two remote devices by calling zb_zdo_bind_req()`for which are needed the addresses, endpoints, and the cluster ID wanted in the binding record. The first parameter (target dstAddr) is the short address of the binding’s source address (where the binding record will be stored) . The remaining parameters are of the remote application device that the bind will use to send frames. Calling :code:`zb_zdo_unbind_req() can be used, with the same parameters, to remove the binding record.

The target device will send back a Zigbee Device Object Bind or Unbind Response message. The ZDO code on the coordinator will parse this and notify the application with either the ZDP transaction sequence number or 0xFF if operation cannot be performed now (nor enough memory, resources, etc.)

Finding and Binding

Base Device Behavior has defined a commissioning method called Finding and Binding, which is a process that relies on the usage of the Identify cluster and ZDO messages to allow the commissioned device to find devices with matching application clusters. This mechanism is usually triggered by the user to specify which devices need to “Find and Bind” each other so that these pairs of devices can communicate more effectively. Refer to section z-stack-overview-finding-binding for further details on this commissioning method.

Routing

Overview

A mesh network is described as a network in which the routing of messages is performed as a decentralized, cooperative process involving many peer devices routing on each others’ behalf.

The routing is completely hidden from the application layer. The application simply sends data destined to any device down to the stack which is then responsible for finding a route. In other words, the application is unaware of the fact that it is operating in a multi-hop network.

Routing also enables the “self healing” nature of Zigbee networks. If a particular wireless link is down, the routing functions will eventually find a new route that avoids that particular broken link. This greatly enhances the reliability of the wireless network and is one of the key features of Zigbee.

Many-to-One routing is a special routing scheme that handles the scenario where centralized traffic is involved. It is part of the Zigbee PRO feature set to help minimize traffic particularly when all the devices in the network are sending packets to a gateway or data concentrator. Many-to-One route discovery is described in detail in section Many-to-One Routing Protocol.

Routing Protocol

Zigbee uses a routing protocol that is based on the AODV (Ad-hoc On-demand Distance Vector) routing protocol for ad-hoc networks. Simplified for use in sensor networks, the Zigbee routing protocol facilitates an environment capable of supporting mobile nodes, link failures and packet losses.

Neighbor routers are routers that are within radio range of each other. Each router keeps track of their neighbors in a “neighbor table”, and the “neighbor table” is updated when the router receives any message from a neighbor router (unicast, broadcast, or beacon).

When a router receives a unicast packet, from its application or from another device, the NWK layer forwards it according to the following procedure. If the destination is one of the neighbors of the router (including its child devices) the packet will be transmitted directly to the destination device. Otherwise, the router will check its routing table for an entry corresponding to the routing destination of the packet. If there is an active routing table entry for the destination address, the packet will be relayed to the next hop address stored in the routing entry. If a single transmission attempt fails, the NWK layer will repeat the process of transmitting the packet and waiting for the acknowledgement, up to a maximum of -nwk data retry times. If an active entry cannot be found in the routing table or using an entry failed after the maximum number of retries, a route discovery is initiated and the packet is buffered until that process is completed.

Zigbee End Devices do not perform any routing functions. An end device wishing to send a packet to any device simply forwards it to its parent device which will perform the routing on its behalf. Similarly, when any device wishes to send a packet to an end device and initiate route discovery, the parent of the end device responds on its behalf.

Also in Zigbee 3.0, the routing implementation has optimized the routing table storage. In general, a routing table entry is needed for each destination device. But by combining all the entries for end devices of a particular parent with the entry for that parent device, storage is optimized without loss of any functionality.

Zigbee routers, including the coordinator, perform the following routing functions: - Route discovery and selection - Route maintenance - Route expiry These are explained in more detail below.

Route Discovery and Selection

Route discovery is the procedure whereby network devices cooperate to find and establish routes through the network. A route discovery can be initiated by any router device and is always performed in regard to a particular destination device. The route discovery mechanism searches all possible routes between the source and destination devices and tries to select the best possible route.

Route selection is performed by choosing the route with the least possible cost. Each node constantly keeps track of “link costs” to all of its neighbors. The link cost is typically a function of the strength of the received signal. By adding up the link costs for all the links along a route, a “route cost” is derived for the whole route. The routing algorithm tries to choose the route with the least “route cost”.

Routes are discovered by using request/response packets. A source device requests a route for a destination address by broadcasting a Route Request (RREQ) packet to its neighbors. When a node receives an RREQ packet it in turn rebroadcasts the RREQ packet. But before doing that, it updates the cost field in the RREQ packet by adding the link cost for the latest link and makes an entry in its Route Discovery Table.

This way, the RREQ packet carries the sum of the link costs along all the links that it traverses. This process repeats until the RREQ reaches the destination device. Many copies of the RREQ will reach the destination device traveling via different possible routes. Each of these RREQ packets will contain the total route cost along the route that it traveled. The destination device selects the best RREQ packet and sends back a Route Reply (RREP) back to the source.

The RREP is unicast along the reverse routes of the intermediate nodes until it reaches the original requesting node. As the RREP packet travels back to the source, the intermediate nodes update their routing tables to indicate the route to the destination. The Route Discovery Table, at each intermediate node, is used to determine the next hop of the RREP traveling back to the source of the RREQ and to make the entry in to the Routing Table.

Once a route is created, data packets can be sent. When a node loses connectivity to its next hop (it doesn’t receive a MAC ACK when sending data packets), the node invalidates its route by sending an RERR to all nodes that potentially received its RREP and marks the link as bad in its Neighbor Table. Upon receiving a RREQ, RREP, or RERR, the nodes update their routing tables.

Route Maintenance

Mesh networks provide route maintenance and self healing. Intermediate nodes keep track of transmission failures along a link. If a link (between neighbors) is determined as bad, the upstream node will initiate route repair for all routes that use that link. This is done by initiating a rediscovery of the route the next time a data packet arrives for that route. If the route rediscovery cannot be initiated, or it fails for some reason, a route error (RERR) packet is sent back to source of the data packet, which is then responsible for initiating the new route discovery. Either way the route gets re-established automatically.

Route Expiry

The routing table maintains entries for established routes. If no data packets are sent along a route for a period of time, the route will be marked as expired. Expired routes are not deleted until space is needed. Thus routes are not deleted until it is absolutely necessary.

Table Storage

The routing functions require the routers to maintain some tables.

Routing Table

Each Zigbee router, including the Zigbee coordinator, contains a routing table in which the device stores information required to participate in the routing of packets. Each routing table entry contains the destination address, the next hop node, and the link status. All packets sent to the destination address are routed through the next hop node. Also entries in the routing table can expire in order to reclaim table space from entries that are no longer in use.

Routing table capacity indicates that a device routing table has a free routing table entry or it already has a routing table entry corresponding to the destination address. The routing table size is configured by ZB_CONFIG_NWK_ROUTING_TABLE_SIZE in the zb_mem_config_common.h file. See the section on Route Maintenance for route expiration details.

Route Discovery Table

Router devices involved in route discovery, maintain a route discovery table. This table is used to store temporary information while a route discovery is in progress. These entries only last for the duration of the route discovery operation. Once an entry expires it can be used for another route discovery operation. Thus this value determines the maximum number of route discoveries that can be simultaneously performed in the network.

Many-to-One Routing Protocol

The following explains Many-to-One and source routing procedure for users’ better understanding of Zigbee routing protocol. In reality, all routings are taken care in the network layer and transparent to the application. Issuing Many-to-One route discovery and route maintenance are application decisions.

Many-to-One Routing Overview

Many-to-One routing is adopted in Zigbee PRO to help minimize traffic particularly when centralized nodes are involved. It is common for low power wireless networks to have a device acting as a gateway or data concentrator. All nodes in the networks shall maintain at least one valid route to the central node. To achieve this, all nodes have to initiate route discovery for the concentrator, relying on the existing Zigbee AODV based routing solution. The route request broadcasts will add up and produce huge network traffic overhead. To better optimize the routing solution, Many-to-One routing is adopted to allow a data concentrator to establish routes from all nodes in the network with one single route discovery and minimize the route discovery broadcast storm.

Source routing is part of the Many-to-One routing that provides an efficient way for concentrator to send response or acknowledgement back to the destination. The concentrator places the complete route information from the concentrator to the destination into the data frame which needs to be transmitted. It minimizes the routing table size and route discovery traffic in the network.

Many-to-One Route Discovery

The following figure shows an example of the Many-to-One route discovery procedure. To initiate Many-to-One route discovery, the concentrator broadcast a Many-to-One route request to the entire network. Upon receipt of the route request, every device adds a route table entry for the concentrator and stores the one hop neighbor that relays the request as the next hop address. No route reply will be generated.

Figure 24. Many-to-One route discovery illustration

Many-to-One route request command is similar to unicast route request command with same command ID and payload frame format. The option field in route request is Many-to-One and the destination address is 0xFFFC.

Route Record Command

The above Many-to-One route discovery procedure establishes routes from all devices to the concentrator. The reverse routing (from concentrator to other devices) is done by route record command (source routing scheme). The procedure is provided in the Route record command (source routing) illustration. R1 sends data packet DATA to the concentrator using the previously established Many-to-One route and expects an acknowledgement back. To provide a route for the concentrator to send the ACK back, R1 sends route record command along with the data packet which records the routing path the data packet goes through and offers the concentrator a reverse path to send the ACK back.

Figure 25. Route record command (source routing) illustration

Upon receipt of the route record command, devices on the relay path will append their own network addresses to the relay list in the route record command payload. By the time the route record command reaches the concentrator, it includes the complete routing path through which the data packet is relayed to the concentrator. Whenever the concentrator sends an APS ACK to R1 in response to a data frame (not due to a route record command itself), it shall include the source route (relay list) in the network layer header of the packet. All devices receiving the packet shall relay the packet to the next hop device according to the source route.

A concentrator with no memory constraints can store all route record entries it receives and use them to send packets to the source devices in the future. Therefore, devices only need to send a route record command once. However, for a concentrator without source route caching capability, devices always need to send route record commands along with data packets. The concentrator will store the source route temporarily in the memory and then discard it after usage.

In brief, Many-to-One routing is an efficient enhancement to the regular Zigbee unicast routing when most devices in the network are funneling traffic to a single device. As part of the Many-to-One routing, source routing is only utilized under certain circumstances. First, it is used when the concentrator is responding to a request initiated by the source device. Second, the concentrator should store the source route information for all devices if it has sufficient memory. If not, whenever devices issue requests to the concentrator, they should also send a route record along with it.

Many-to-One Route Maintenance

If a link failure is encountered while a device is forwarding a Many-to-One routed frame (notice that a Many-to-One routed frame itself has no difference from a regular unicast data packet, however, the routing table entry has a field to specify that the destination is a concentrator), the device will generate a network status command with code “Many-to-One route failure”. The network status command will be relayed to the concentrator through a random neighbor and hopefully that neighbor still has a valid route to the concentrator. When the concentrator receives the route failure, the application will decide whether or not to re-issue a Many-to-One route request.

Router Off-Network Association Cleanup

In case a Zigbee Router gets off network for a long period of time, its children will try to join an alternative parent. When the router is back online, the children will still appear in its child table, preventing proper routing of egress traffic to them.

Portable Devices

An End Device detects that a parent isn’t responding either through polling (MAC data requests) failures and/or through data message failures.

When the network layer detects that its parent isn’t responding, it will trigger the process of scanning the channel in which this device was commissioned, in order to search another suitable parent device. It is recommended that as soon as an end device loses its parent, it should try to recover. If recovery fails, the device should try once again after a short delay, and if it still fails, it should retry periodically with a larger waiting period. This practice allows for better power usage on the end device and does not interfere with other networks that may be on the same channel.

In secure networks, it is assumed that the device already has a key and a new key isn’t issued to the device.

The end device’s short address is retained when it moves from parent to parent; routes to such end devices are re-established automatically.

End-to-End Acknowledgements

For non-broadcast messages, there are basically 2 types of message retries: end-to-end acknowledgement (APS ACK) and single-hop acknowledgement (MAC ACK). MAC ACKs are always on by default and are usually sufficient to guarantee a high degree of reliability in the network. To provide additional reliability, as well as to enable the sending device to get confirmation that a packet has been delivered to its destination, APS acknowledgements may be used.

APS acknowledgement is done at the APS layer and is an acknowledgement system from the destination device to the source device. The sending device will hold the message until the destination device sends an APS ACK message indicating that it received the message.

Miscellaneous

Configuring Channel

Every Zigbee 3.0 device has a primary channel mask configuration (DEFAULT_CHANLIST). For devices with formation capabilities that were instructed to create a network, these channels masks are used when scanning for a channel with the least number of networks to create the new network on. For devices with joining capabilities that were instructed to join a network, these channel masks are used when scanning for existing networks to join. The device will try first with all the channels defined in the primary channel mask. If the process is not successful (the network was not created or no network to join was found), then the secondary channel mask is used. These two channel masks can be configured by the application as needed. A value of 0 in one of these masks will disable the respective channel scanning phase (primary or secondary).

The default primary channel mask is defined as DEFAULT_CHANLIST, in ti_zigbee_config.h, which is generated from the project’s .syscfg (RF STACKS → Zigbee → Radio). The z-stack-overview-commissioning section provides more details on the commissioning methods.

Configuring the PAN ID and Network to Join

The 16-bit PANID of a network is determined by the ZDAPP_CONFIG_PAN_ID parameter in ti_zstack_config.h, as generated by the .syscfg file of the project (see Zigbee Configuration).

If set to a value between 0x0000 and 0xFFFE (inclusive), a coordinator or a network-forming router will use this value as the PAN ID of the network when instructed to create a network, and a joining router or end device will only join a network that has a PAN ID which matches the value of this parameter.

If set to 0xFFFF, a newly formed network will have a random PAN ID, and a joining device will be able to join any network regardless of its PAN ID.

This is an optional configuration item to control which network a Zigbee Router or End Device will join. It can also be used to pre-set the PAN ID of a new network that a coordinator or router will create.

The network discovery process is managed by the Network Steering commissioning process, which is explained in z-stack-overview-nwk-steering-not-on-nwk. It allows filtering of the discovered networks. After the scan (using either primary or secondary channel masks) is complete, the application receives a list of network descriptors of the networks found during the scan.

Maximum Payload Size

The maximum payload size for an application is based on several factors. The MAC layer provides a constant payload length of 125 bytes. The NWK layer requires a fixed header size, one size with security and one without security. The APS layer has a required, but variable, header size based on a variety of settings, including the Zigbee Protocol Version, APS frame control settings, etc. Ultimately, the user does not have to calculate the maximum payload size using the aforementioned factors.

Leave Network

The ZDO Management implements the function zb_zdo_mgmt_leave_req(), which provides access to the “NLME-LEAVE.request” primitive. “NLME-LEAVE.request” allows a device to remove itself or a remote device from the network. When a device removes a child device, it also removes the device from the local “association table”. The NWK address will only be reused in the case where a child device is a Zigbee End Device. In the case of a child Zigbee Router, the NWK address will not be reused.

If the parent of a child device leaves the network, the child will stay on the network.

Since R21 of the Zigbee PRO specification, processing of “NWK Leave Request” has been configurable for Routers. Processing of these commands, depending on the logical device type, has also changed: Coordinators do not process leave commands, Router devices process leave commands from any device in the network (if allowed as mentioned above), and end devices only process leave commands from their parent device.

In the Base Device Behavior Specification, it is also stated that if any device receives a valid leave request with rejoin set to FALSE (meaning that this device shall not rejoin the network), then that device is forced to perform a Factory New reset. In this case, Zigbee 3.0 clears all the Zigbee persistent data, while it is up to the application to clear the relevant application data from NV.

Descriptors

All devices in a Zigbee network have descriptors that describe the type of device and its applications. This information is available to be discovered by other devices in the network.

Asynchronous Links

An asynchronous link occurs when a node can receive packets from another node but it can’t send packets to that node. Whenever this happens, this link is not a good link to route packets.

In Zigbee PRO, this problem is overcome by the use of the Network Link Status message. Every router in a Zigbee PRO network sends a periodic Link Status message. This message is a one hop broadcast message that contains the sending device’s neighbor list. The idea is this – if you receive your neighbor’s Link Status and you are either missing from the neighbor list or your receive cost is too low (in the list), you can assume that the link between you and this neighbor is an asynchronous link and you should not use it for routing.

To change the time between Link Status messages you can change the compile flag ZB_NWK_LINK_STATUS_PERIOD. Remember that only PRO routers send the link status message and that every router in the network must have the same Link Status time period.

Another parameter that affects the Link Status message is ZB_NWK_ROUTER_AGE_LIMIT (default of 3). This represents the number of Link Status periods that a router can remain in a device’s neighbor list, without receiving a Link Status from that device, before it becomes aged out of the list. If a device doesn’t received a Link Status message from a neighbor within (ZB_NWK_ROUTER_AGE_LIMIT * ZB_NWK_LINK_STATUS_PERIOD), the device will age the neighbor out and assume that this neighbor is missing or that it’s an asynchronous link and not use it.

Multicast Messages

This feature is a Zigbee PRO only feature. This feature is similar to sending to an APS Group, but at the network layer.

A multicast message is sent from a device to a group as a MAC broadcast message, which includes a non-member radius field. The receiving device will determine if it is part of that group. If it isn’t part of the group, then it will decrement the non-member radius and rebroadcast. If it is part of the group, then it will first set the non-member radius equal to the group radius, and then rebroadcast the message. If the non-member radius is decremented to 0, the message isn’t rebroadcast.

The difference between multicast and APS group messages can only be seen in very large networks, where the non-member radius will limit the number of hops away from the group.

Fragmentation

Message Fragmentation is a process where a large message – too large to send in one APS packet – is broken down and transmitted as smaller fragments. The fragments of the larger message are then reassembled by the receiving device.

When APS Fragmentation is turned on, sending a data request with a payload larger than a normal data request payload will automatically trigger fragmentation.

Extended PAN IDs

By default, the 64-bit Extended PAN ID (EPID) is set to the device’s own IEEE address. If a pre-determined EPID is required, the developer changes this in the project’s .syscfg file.

Rejoining with Pre-Commissioned Network Parameters

In previous Zigbee stacks, it was possible for a rejoining device to use a pre-configured network address. As of today, the Base Device Behavior specification has not addressed this topic (whether this is allowed or not). TI encourages the use of the Base Device Behavior commissioning methods described in z-stack-overview-commissioning for rejoining the network.