Zigbee platform designs

Table of Contents

• System-on-Chip designs
  • Single-chip, single protocol (SoC)
  • Single-chip, multiprotocol (SoC)
• Co-processor designs
  • Split-stack co-processor design
  • CLI co-processor design

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.

The Zigbee stack supports:

• System-on-Chip designs
• Co-processor designs

---

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.

Single-chip, single protocol (SoC)

In this design, the application layer and the stack run on the same processor. The application uses the ZBOSS APIs directly.

This is the SoC design most commonly used for end devices and routers.

This design has the following advantages:

• Lowest cost.
• Lowest power consumption.
• Lowest complexity.

It also has the following disadvantages:

• For some uses, the nRF528xx MCU can be too slow. For example, when the application would like to do complex data processing.
• The application and the network share Flash and RAM space, which can limit the application functionality.
• Dual-bank DFU or an external flash is needed to update the firmware.

Figure 1. Zigbee-only architecture.

For more information, see Zigbee and Zigbee+BLE examples.

Single-chip, multiprotocol (SoC)

With the nRF52 devices supporting multiple wireless technologies, including IEEE 802.15.4 and Bluetooth Low Energy (BLE), the application layer and the Zigbee and BLE stack run on the same processor.

This design has the following advantages:

• It leverages the benefits of highly integrated SoC, resulting in the lowest cost and the lowest power consumption.
• It allows to run Zigbee and BLE simultanously on a single chip, which reduces the overall BOM cost.

It also has the following disadvantages:

• BLE activity can degradate the connectivity on Zigbee if not implemented with efficiency in mind.

Figure 2. Multiprotocol Zigbee and BLE architecture.

For more information, see Multiprotocol support with BLE/Bluetooth and Zigbee multiprotocol examples.

---

Co-processor designs

The co-processor designs can be used when a more powerful processor (host) that does not have a suitable radio interface. In these designs, the host interacts with the Zigbee network through Network Co-Processor (NCP).

In the split-stack co-processor design, the stack operates both on host and NCP. In the CLI design, the stack operates on the NCP.

Split-stack co-processor design

In this design, the host procesor runs the Zigbee application layer (ZCL) and the Zigbee Pro network layer. The NCP runs the Zigbee MAC layer. The host processor communicates with the NCP through a serial interface (typically UART).

Figure 3. Split Zigbee architecture.

This design has the following advantages:

• Cost-optimized solution - uses the resources on the more powerful processor.

It also has the following disadvantages:

• The host part of the stack must be built and run for every individual host processor in use.
• The Zigbee inner operations (like packet routing) influence the performance of the host processor.
• A separate Zigbee Alliance Platform Certification is required for any combination of host processor and nRF52, as a prerequisite to Zigbee Product Certification.
• Dynamic multiprotocol with Bluetooth is not possible with this design.

Note

The split-stack co-processor design is not part of the nRF5 SDK for Thread and Zigbee, but can be provided by a Nordic partner.

CLI co-processor design

In this design, the NCP runs the whole Zigbee stack. The host processor can interact with the Zigbee network using a text-based command line interface (CLI). The CLI is exposed to the host procesor over a serial interface (typically UART or USB).

This is the official Nordic design intended for gateway solutions.

Figure 4. CLI Zigbee architecture.

This design has the following advantages:

• Ease of development on the host side - the Zigbee part of the gateway is independent from the host processor in use.
• The Zigbee inner operations (like packet routing) do not influence the performance of the host processor (since they are executed remotely on a peripheral SoC).
• The Zigbee Alliance Platform Certification is preserved for any product. A product has to execute only Zigbee Product Certification.
• This design supports dynamic multiprotocol with Bluetooth.

It also has the following disadvantages:

• Higher cost of the peripheral SoC.
• ZCL Server Clusters cannot be used on the host processor.

See the Zigbee CLI Agent example and Zigbee CLI Reference for the CLI example and the list of supported commands, respectively.

The Zigbee CLI wrapper library provides a convenient Python interface to the CLI. It also includes an example of how this design can be used for the implementation of a Zigbee-MQTT gateway.