An Open Foundation for the Connected Home

By Jonathan

The Origin of Thread

The moment Nest expanded our product line beyond the Nest Learning Thermostat, we were in new territory. Multiple smart home devices not only needed to talk to users, but also to each other in a reliable and secure manner.

Imagine a home with multiple Nest Protects — one upstairs, one downstairs. It’s night. Everyone’s asleep. The downstairs Protect detects smoke, but no one hears the alarm — perhaps it’s too far away, or doors are closed. However, if all Protects are connected together, they can talk to each other. The upstairs Protect can also sound an alarm, successfully alerting everyone upstairs.

Why not just use Wi-Fi to do this? Nest Protects are low-power devices — some operate only on batteries. Using Wi-Fi to send messages, to and from the cloud or even locally, requires power that makes it less suitable for battery-operated devices. Why not Bluetooth? Bluetooth is a point-to-point communication protocol, which makes it less suitable for efficiently communicating messages across a network of devices, and lacks IPv6, which limits its longevity.

To facilitate reliable communication between Nest Protects, we built a networking protocol that requires less power and overcomes the limitations of point-to-point and hub-and-spoke communications. And to enable robust, remote connectivity in a rapidly growing IoT ecosystem, we built in IPv6 from the ground up, while simultaneously baking-in strong link-layer security. With these requirements in mind, and in collaboration with a number of like-minded revolutionary partners, Thread was born.

Going Open Source

We could have limited our Thread contributions to specification development within the Thread Group. However, after seeing the value proposition of Thread, we wanted the benefits of Thread technology to be more broadly adopted — to accelerate the development of products for the connected home and beyond. It was clear that we needed to make Thread technology widely available to our partners and the IoT community.

So, in 2016, Nest released an open-source version of Thread, called OpenThread. It is the first open-source Thread Certified Component, implementing all features defined in the Thread 1.1.1 specification.

OpenThread is OS and platform agnostic, with a narrow platform abstraction layer and a small memory footprint, making it highly portable to a wide spectrum of hardware system architectures. Due to this flexible design, OpenThread has been ported to multiple hardware platforms, such as Dialog’s DA15000, Nordic’s nRF52840, NXP’s KWx1Z, Silicon Labs’ EFR32, Texas Instruments’ CC2538 and CC2650, and Microsoft’s Windows 10, by both the OpenThread team and the community.

The Benefits of Open Source

Source access makes it easy for both silicon vendors and the developer community to port OpenThread to new hardware platforms, resulting in more silicon choices. It also results in a single code base that can be used across multiple hardware and product designs (more on that later). This enables developers to support each other more efficiently.

Open source creates transparency when it comes to testing and security audits — something you may not get with a proprietary product. Not only are our testing tools and security features public, the community can add new tests, easily notify us of issues and contribute to the hardening of OpenThread.

From a business perspective, using open-source firmware reduces business constraints. It allows silicon vendors to easily incorporate and extend OpenThread for their customers. Developers can easily include OpenThread in their products, thus allowing them to easily create value-added products and services.

We’ve released OpenThread under a permissive open-source BSD-3 copyright license. This license makes it painless for users to debug issues and provide feedback and enhancements to the project.

How does it work?

OpenThread is designed with portability and flexibility in mind. The code is portable C/C++ (C99 and C++03) that’s system architecture-agnostic due to a narrow abstraction layer. This abstraction layer means that OpenThread can run on either bare-metal or an OS. To date, OpenThread has been demonstrated to run on FreeRTOS, RIOT-OS, Linux, macOS and Windows.

OpenThread’s portable nature makes no assumptions about platform features. OpenThread provides the hooks to utilize enhanced radio and crypto 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.

The portable design is also why it’s so flexible. OpenThread has a configurable build system with which a developer can enable or disable features as needed. Beyond the default GNU toolchain, the source is designed to work with a number of other popular toolchains like IAR and Visual Studio.

Platform designs

OpenThread supports both system-on-chip (SoC) and network co-processor (NCP) designs.

An SoC is a single-chip solution that has the combined RFIC (802.15.4 in the case of Thread) and processor, where OpenThread and the application layer run on the local processor.

An NCP design is where the application layer runs on a host processor and communicates with OpenThread via a serial connection using a standardized host-controller protocol we call Spinel. In this design, OpenThread can run on either the radio or host processor.

Let’s dive into the different flavors of these designs.

Single-Chip, Thread-Only (SoC)

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

This is the typical SoC design most commonly used for end devices. Because it is highly-integrated into a single silicon, it has the lowest cost and lowest power consumption.

Single-Chip, Multiple-Interface (SoC)

Even when a SoC has multiple radios, such as 802.15.4 and Wi-Fi, or 802.15.4 and Bluetooth Low Energy (BLE), the application layer and OpenThread still run on the same processor. In the multiple-interface design, OpenThread leverages the shared third-party IPv6 stack via a raw IPv6 datagram interface.

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 (but has greater power demands) than the OpenThread device. The host processor communicates with the OpenThread device via 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.

Host / 802.15.4 Controller

There 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 doesn’t sleep in this design, in part to ensure reliability in the Thread network.

The advantage here is that OpenThread can utilize the resources on the more powerful processor.

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.

Other features

With OpenThread, you get more than just the Thread 1.1.1 Specification. We’ve added a number of features and enhancements ranging from APIs to additional protocols that facilitate host/NCP communications.

For example, our complete APIs allow you to integrate OpenThread with a third-party IPv6 stack, build application layers that rely on UDP messages, or resolve DNS names to IPv6 address. With CoAP client and server support, you can share the same CoAP implementation between OpenThread and CoAP-based applications.

We’ve added a Command Line Interface (CLI) for easier configuration and network management. The CLI can also be used by automated test scripts.

We’ve also included the Spinel protocol for NCP designs, which enables communication between the host device and the NCP. Sniffer support is exposed by Spinel, and the wpantund daemon provides an IPv6 interface to the NCP.

Interested in OpenThread?

There are multiple ways to learn more and get involved:

• Check out this workshop from March
• Run through our Simulation Codelab, which covers all the basics of OpenThread, without the need for test hardware — all you need is a Mac or Linux machine
• Get a devkit — explore the platforms OpenThread already supports

You can also catch us in the IoT Sandbox at Google I/O this week in Mountain View, California.

Join the conversation at Nest’s Developer community. Get started with Nest Developers. Or explore careers with Nest.

The information contained in this blog is provided only as general information for educational purposes, and may or may not be up to date. The information is provided as-is with no warranties. This blog is not intended to be a factual representation of how Nest’s products and services actually work. No license is granted under any intellectual property rights of Nest, Google, or others.