OpenThread platform designs

Table of Contents

• System-on-Chip designs
  • Single-chip, single protocol (SoC)
  • Single-chip, multiprotocol (SoC)
• Co-processor designs
  • Network Co-Processor (NCP)
  • Radio Co-Processor (RCP)
• Spinel NCP Protocol usage
  • Spinel support on application processors

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
• Co-processor designs

---

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 end devices. Because it is highly integrated into a single silicon, it has the lowest cost and power consumption.

Figure 1. Thread-only architecture.

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

Single-chip, multiprotocol (SoC)

With nRF52840 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 solution still leverages the benefits of highly integrated SoC, resulting in the lowest cost and the lowest power consumption.

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.

The benefit of this design is that the higher-power host can sleep, while the lower-power OpenThread device remains active to maintain its place in the Thread network. And since the SoC is not tied to the application layer, development and testing of applications is independent of the OpenThread build.

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

For more information, see Thread NCP/RCP Example.

Figure 3. Network Co-Processor architecture.

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.

The advantage of this design is that OpenThread can utilize the resources on the more powerful processor. Therefore, its another benefit is the usage of less capable co-processor in comparison to the NCP solution.

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.

Figure 4. Radio Co-Processor architecture.

For more information, see Thread NCP/RCP Example.

---

Spinel NCP Protocol usage

By default, the OpenThread stack uses the Spinel NCP Protocol for serialization of network and to control data over a serial link. The protocol supports encapsulation of IPv6 packets and 802.15.4 frames, which allows for using the NCP full stack or RCP tunnel modes. It also provides control over the co-processor state (for example, change power state) and 802.15.4 PHY and MAC parameters.

Thread NCP/RCP Example provides a reference implementation of an OpenThread NCP and RCP for nRF52840 and nRF52811.

Spinel support on application processors

Use one of the following modules to provide the Spinel support on application processors, depending on your needs:

• WPAN Network Deamon (wpantund), which provides an implementation of the Spinel protocol for POSIX-compliant application processors.
  • The deamon provides:
    • a user-space network interface that exposes a native IPv6 network interface to the Thread network;
    • a set of command line tools to manage the NCP state and its behavior on the Thread network.
  • In the Thread Border Router example, wpantund runs on a Raspberry Pi and is used to forward IPv6 traffic between Thread and external networks.
• pyspinel Python module, which provides several functions implemented by wpantund.
  • PySpinel allows for connecting to a Thread network using the full stack mode and controlling an NCP from a Python script.
  • PySpinel is used in nrfutil for Thread (available from nRF5 SDK for Thread web page) for connecting to a Thread network from an application and performing the device firmware update (DFU).
  • In the nRF5 SDK for Thread and Zigbee there is no implementation of the Spinel protocol for non-POSIX application processors in this SDK.

---

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.