OpenThread architectures

This page describes the OpenThread stack architecture and platform designs that are possible with the OpenThread network stack on Nordic Semiconductor devices in nRF Connect SDK.

The designs are described from the least complex to the most complex, starting with System-on-Chip designs. These are simple applications that consist of a single chip running a single protocol or multiple protocols. Co-processor designs, on the other hand, require two processors. The nRF SoC acts as a network co-processor, while the application is running on a much more powerful host processor.

OpenThread stack architecture

OpenThread’s portable nature makes no assumptions about platform features. OpenThread provides the hooks to use enhanced radio and cryptography features, reducing system requirements, such as memory, code, and compute cycles. This can be done per platform, while retaining the ability to default to a standard configuration.

OpenThread architecture

OpenThread architecture adapted from openthread.io

System-on-Chip designs

A single-chip solution uses the RFIC (the IEEE 802.15.4 in case of Thread) and the processor of a single SoC.

In these designs, OpenThread and the application layer run on the same local processor.

Single-chip, single protocol (SoC)

In this design, the only wireless protocol that is used is Thread. OpenThread and the application layer run on the same processor. The application uses the OpenThread APIs and IPv6 stack directly.

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

This design has the following advantages:

  • The radio and the general MCU functionalities are combined into one chip, resulting in a low cost.

  • Power consumption is lower than in all other designs.

  • Complexity is lower than in all other designs.

It has the following disadvantages:

  • For some use cases, the nRF52 Series and nRF53 Series MCUs can be too slow (for example, when the application does 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.

Thread-only architecture (nRF52)

Thread-only architecture on nRF52 Series devices

Thread-only architecture (nRF53)

Thread-only architecture on nRF53 Series devices

This platform design is suitable for the following development kits:

Hardware platforms

PCA

Board name

Build target

nRF52840 DK

PCA10056

nrf52840dk_nrf52840

nrf52840dk_nrf52840

nRF52833 DK

PCA10100

nrf52833dk_nrf52833

nrf52833dk_nrf52833

nRF5340 DK

PCA10095

nrf5340dk_nrf5340

nrf5340dk_nrf5340_cpuapp

nrf5340dk_nrf5340_cpuapp_ns

nRF21540 DK

PCA10112

nrf21540dk_nrf52840

nrf21540dk_nrf52840

Single-chip, multiprotocol (SoC)

nRF52 and nRF53 Series devices support multiple wireless technologies, including IEEE 802.15.4 and Bluetooth® Low Energy (Bluetooth LE).

In a single-chip, multiprotocol design, the application layer and OpenThread run on the same processor.

This design has the following advantages:

  • It leverages the benefits of a highly integrated SoC, resulting in low cost and low power consumption.

  • It allows to run Thread and Bluetooth LE simultaneously on a single chip, which reduces the overall BOM cost.

It has the following disadvantages:

  • Bluetooth LE activity can degrade the connectivity on Thread if not implemented with efficiency in mind.

Multiprotocol Thread and Bluetooth LE architecture (nRF52)

Multiprotocol Thread and Bluetooth LE architecture on nRF52 Series devices

Multiprotocol Thread and Bluetooth LE architecture (nRF53)

Multiprotocol Thread and Bluetooth LE architecture on nRF53 Series devices

For more information about the multiprotocol feature, see Multiprotocol support.

This platform design is suitable for the following development kits:

Hardware platforms

PCA

Board name

Build target

nRF52840 DK

PCA10056

nrf52840dk_nrf52840

nrf52840dk_nrf52840

nRF52833 DK

PCA10100

nrf52833dk_nrf52833

nrf52833dk_nrf52833

nRF5340 DK

PCA10095

nrf5340dk_nrf5340

nrf5340dk_nrf5340_cpuapp

nrf5340dk_nrf5340_cpuapp_ns

Co-processor designs

In co-processor designs, the application runs on one processor (the host processor) and communicates with another processor that provides the Thread radio. The communication happens through a serial connection using a standardized host-controller protocol (Spinel). See OpenThread co-processor communication for more information on the communication.

OpenThread runs on either the radio processor or the host processor, depending on whether a network co-processor (NCP) design or a radio co-processor (RCP) design is chosen.

Network co-processor (NCP)

In the standard NCP design, the full OpenThread stack runs on the processor that provides the Thread radio (the network processor), and the application layer runs on a host processor. The host processor is typically more capable than the network processor, but it has greater power demands. The host processor communicates with the network processor through a serial interface (typically UART or SPI) 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:

  • The higher-power host can sleep, while the lower-power network processor remains active to maintain its place in the Thread network.

  • Since the network processor is not tied to the application layer, development and testing of applications is independent of the OpenThread build.

  • When choosing an advanced and powerful host processor, applications can be very complex.

  • Only the network stack and a thin application reside on the network processor, which reduces the cost of the chip. RAM and flash usage are usually smaller than in a single-chip solution.

  • This design does not require support for dual-bank DFU, because the host can just replace the old image with a new one.

It has the following disadvantages:

  • This is a more expensive option, because it requires a host processor for the application.

Network co-processor architecture

Network co-processor architecture

Note

Spinel connections through SPI and USB are not currently available.

This platform design is currently discontinued by nRF Connect SDK.

Radio co-processor (RCP)

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

This design is useful for devices that are less sensitive to power constraints.

This design has the following advantages:

  • OpenThread can use the resources on the more powerful host processor.

  • When choosing an advanced and powerful host processor, applications can be very complex.

  • It is possible to use a radio co-processor that is less capable than what is needed in the NCP design, which reduces the cost.

It has the following disadvantages:

  • The host processor must be woken up on each received frame, even if a frame must be forwarded to the neighboring device.

  • The RCP solution can be less responsive than the NCP solution, due to the fact that each frame or command must be communicated to the host processor over the serial link.

Radio co-processor architecture

Radio co-processor architecture

Note

Spinel connections through SPI and USB are not currently available.

This platform design is suitable for the following development kits:

Hardware platforms

PCA

Board name

Build target

nRF52840 DK

PCA10056

nrf52840dk_nrf52840

nrf52840dk_nrf52840

nRF52833 DK

PCA10100

nrf52833dk_nrf52833

nrf52833dk_nrf52833

nRF21540 DK

PCA10112

nrf21540dk_nrf52840

nrf21540dk_nrf52840

UART recommendations for NCP

Use the following recommended default UART settings for configuration based on Network co-processor (NCP) architecture:

  • Bit rate: 1000000

  • Start bits: 1

  • Data bits: 8

  • Stop bits: 1

  • No parity

  • Flow Control: Hardware

Flow control

UART Hardware Flow Control is recommended in Nordic Semiconductor’s solution. Using Software Flow Control is neither recommended nor implemented.

Hardware reset

Use the Arduino-style hardware reset, where the DTR signal is coupled to the RES pin through a 0.01 µF capacitor. This causes the NCP to automatically reset whenever the serial port is opened.

Note

This hardware reset method is not used in Nordic Semiconductor’s solution. Dedicate one of your host pins to control the RES pin on the NCP, so that you can easily perform a hardware reset if necessary.