Zigbee architectures
Note
Support for Zigbee R22 has been deprecated in nRF Connect SDK v2.8.0 and it will be removed in one of the future releases, following the deprecation policy. As a result, the nRF52833, nRF52840 and nRF5340 SoCs are not recommended for new Zigbee designs. Experimental support for Zigbee R23 is available for the nRF54L Series as an nRF Connect SDK Add-on.
This page describes the platform designs that are possible with the Zigbee stack on Nordic Semiconductor devices.
The designs are described from the least to the most complex, that is from simple applications that consist of a single chip running single or multiple protocols to scenarios in which the nRF SoC acts as a network co-processor when the application is running on a much more powerful host processor.
System-on-Chip designs
This single-chip solution has the combined RFIC (the IEEE 802.15.4 in case of Zigbee) and processor. The Zigbee stack and the application layer run on the local processor.
This design has the following advantages:
Lowest cost
Lowest power consumption
Lowest complexity
It also has the following disadvantages:
For some uses, the nRF SoC’s MCU can be to slow to handle both the application and the network stack load.
The application and the network stack share flash and RAM space. This leaves less resources for the application.
Dual-bank DFU or an external flash is needed to update the firmware.
Single-chip, single protocol (SoC)
In this design, the application layer and the stack run on the same processor. The application uses the ZBOSS Zigbee stack APIs directly.
This is the design most commonly used for End Devices and Routers.
Zigbee-only architecture on nRF52 Series devices
Zigbee-only architecture on nRF53 Series devices
This platform design is suitable for the following development kits:
Hardware platforms |
PCA |
Board name |
Board target |
|---|---|---|---|
PCA10056 |
|
||
PCA10100 |
|
||
PCA10095 |
|
||
PCA10112 |
|
Single-chip, multiprotocol (SoC)
With the nRF devices supporting multiple wireless technologies, including IEEE 802.15.4 and Bluetooth® Low Energy (Bluetooth LE), the application layer and the Zigbee and Bluetooth LE stack run on the same chip.
This design has the following advantages:
It allows to run Zigbee and Bluetooth LE simultaneously on a single chip, which reduces the overall BOM cost.
It also has the following disadvantages:
Bluetooth LE activity can degradate the connectivity on Zigbee if not implemented with efficiency in mind.
Multiprotocol Zigbee and Bluetooth LE architecture on nRF52 Series devices
Multiprotocol Zigbee and Bluetooth LE architecture on nRF53 Series devices
For more information, see Multiprotocol support and Multiprotocol Bluetooth LE extension.
This platform design is suitable for the following development kits:
Hardware platforms |
PCA |
Board name |
Board target |
|---|---|---|---|
PCA10056 |
|
||
PCA10100 |
|
||
PCA10095 |
|
Co-processor designs
In co-processor designs, the application runs on one processor (the host processor) and communicates with another processor that provides the radio interface. In these designs, the more powerful processor (host) interacts with the Zigbee network through a connectivity device, for example a Nordic Semiconductor’s device with the Zigbee interface.
The co-processor designs can be used when a device requires additional functionalities or more compute power than what Nordic Semiconductor’s devices have to offer, but the more powerful processor does not have a suitable radio interface. The split stack architectures are most commonly used to design a Zigbee gateway, but sometimes also for complex Zigbee Routers or Zigbee End Devices.
Network Co-Processor (NCP)
In this design, the host processor runs the Zigbee application layer (ZCL) and the Zigbee commissioning logic. The connectivity device (nRF SoC) runs the NCP application that contains lower parts of the Zigbee stack (802.15.4 PHY/MAC and the Zigbee PRO network layer), as well as provides commands to execute BDB commissioning primitives. The host processor communicates with the NCP through a serial interface (USB or UART).
The NCP design has the following advantages:
Cost-optimized solution - uses the resources on the more powerful processor.
The NCP device does not require the support for the dual-bank DFU. It can be upgraded by the host processor.
Access to the full feature set of ZBOSS.
Lower memory footprint on the connectivity side (as compared with single-SoC Zigbee applications).
It also has the following disadvantages:
The host part of the stack must be built and run for every individual host processor in use. However, Nordic Semiconductor provides reference implementation for Linux-based platforms in the ZBOSS NCP Host package.
Split Zigbee architecture
The nRF Connect SDK includes the ZBOSS NCP Host tool. It contains the full development-ready source code for host and evaluation-ready firmware for the nRF52840 DK, the nRF52833 DK, and the nRF52840 Dongle. The package comes with prebuilt libraries compatible with 64-bit Ubuntu 18.04 Linux.
The tool is available for download as a standalone zip package using the following link:
ZBOSS NCP Host (2.2.4)
For information about how to recompile the package libraries for a different host architecture or operating system, see the NCP Host documentation. For information about how to use NCP Host for Zigbee in the nRF Connect SDK or build the firmware using the NCP sample, see the NCP sample.
This platform design is suitable for the following development kits:
Hardware platforms |
PCA |
Board name |
Board target |
|---|---|---|---|
PCA10056 |
|
||
PCA10100 |
|
||
PCA10112 |
|