nRF5 SDK for Thread and Zigbee v4.1.0
OpenThread platform designs

Table of Contents

This page describes the platform designs that are possible with the OpenThread network 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.

OpenThread supports:


System-on-Chip designs

This single-chip solution has the combined RFIC (the IEEE 802.15.4 in case of Thread) and processor. OpenThread and the application layer run on the local processor.

Single-chip, single protocol (SoC)

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

This is the SoC design most commonly used for applications that do not make heavy computations or are battery powered.

This design has the following advantages:

It also has the following disadvantages:

platform_design_soc.svg
Figure 1. Thread-only architecture.

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

Single-chip, multiprotocol (SoC)

With nRF52840 and nRF52833 supporting multiple wireless technologies, including IEEE 802.15.4 and Bluetooth Low Energy (BLE), the application layer and OpenThread still run on the same processor.

In this multiprotocol design, the SoC ensures either dynamic or switched Thread and BLE connectivity.

This design has the following advantages:

It also has the following disadvantages:

platform_design_multi.svg
Figure 2. Multiprotocol Thread and BLE architecture.

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


Co-processor designs

In the co-processor designs, with either network co-processor (NCP) or radio co-processor (RCP), the application layer runs on a host processor and communicates with OpenThread through a serial connection using a standardized host-controller protocol (Spinel). OpenThread can run on either the radio or the host processor.

Network Co-Processor (NCP)

The standard NCP design has Thread features on the SoC and runs the application layer on a host processor, which is typically more capable than the OpenThread device, although it has greater power demands. The host processor communicates with the OpenThread device through a serial interface (typically SPI or UART) over the Spinel protocol.

This design is useful for gateway devices or devices that have other processing demands, like IP cameras and speakers.

This design has the following advantages:

It also has the following disadvantages:

platform_design_ncp.svg
Figure 3. Network Co-Processor architecture.

For more information, see Thread NCP/RCP Example.

Radio Co-Processor (RCP)

This is a variant of the NCP design where the core of OpenThread lives on the host processor with only a minimal “controller” on the device with the Thread radio. The host processor typically does not sleep in this design, in part to ensure reliability of the Thread network.

This design is useful for devices that are less sensitive to power constraints. For example, the host processor on a video camera is always on to process video.

This design has the following advantages:

It also has the following disadvantages:

platform_design_rcp.svg
Figure 4. Radio Co-Processor architecture.

More information about NCP/RCP

For more information about the NCP/RCP co-processor design, see:


Portions of this page are reproduced from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.


Documentation feedback | Developer Zone | Subscribe | Updated