Supported Thread features

The OpenThread implementation of the Thread protocol supports all features defined in the Thread 1.4 Specification that are required for the Thread 1.4 Certification program:

  • All Thread networking layers:

    • IPv6

    • 6LoWPAN

    • IEEE 802.15.4 with MAC security

    • Mesh Link Establishment

    • Mesh Routing

  • All device roles

  • Border Router support

  • Features introduced with Thread 1.2:

    • Coordinated Sampled Listening (CSL)

    • Link Metrics Probing

    • Multicast across Thread networks

    • Thread Domain unicast addressing

  • Features introduced with Thread 1.3:

    • Service Registration Protocol (SRP) client

    • Transport Control Protocol (TCP)

  • Features introduced with Thread 1.4:

    • Enhanced Internet Connectivity

    • Enhanced Network Diagnostics

    • Secure Commissioning at Scale with TCAT

In the nRF Connect SDK, you can choose which version of the Thread protocol to use in your application. By default, the nRF Connect SDK supports Thread 1.4, which includes support for Thread 1.3 and Thread 1.2. You can enable and configure any Thread version by using dedicated options.

Thread 1.2 features

The nRF Connect SDK implements all mandatory features from the Thread 1.2 Specification.

The features introduced with the Thread 1.2 Specification are fully backward-compatible with implementations using Thread 1.1 (more specifically, the Thread 1.1.1 Specification). Thread 1.2 improves network scalability, responsiveness, density, and power consumption. For more information about this Thread version, see the official Thread 1.2 in Commercial White Paper and the Thread 1.2 Base Features document.

Note

See Thread Specification options for how to enable the 1.2 features that are currently available in the nRF Connect SDK.

Coordinated Sampled Listening (CSL)

Coordinated Sampled Listening defined in IEEE 802.15.4-2015 is introduced by Thread 1.2 Specification to provide low latency communication for Sleepy End Devices (SEDs). Thread 1.2 routers are required to support synchronized CSL transmissions to children which require them. These children are known as Synchronized Sleepy End Devices (SSEDs).

SSEDs are allowed to transmit frames normally at any time, but the routers should use the CSL transmission mechanism as long as the synchronization is maintained. This allows an SSED to stay in a sleepy state more than 99% of the time and only turn on its radio periodically for a few hundreds of microseconds in order to receive frames from its parent.

The most common use case for SSEDs is for developing battery-powered actuators with low latency, such as window blinds.

Multicast across Thread networks

Thread 1.1 border routers have a limitation not to forward multicast traffic with a scope greater than realm-local. For certain applications it could be useful to be able to control multicast groups from a host outside the Thread network. This is achieved in Thread 1.2 by allowing Thread border routers to forward multicast traffic with a scope greater than realm-local in two ways:

  • From the Thread network to the exterior network: as a configuration option in the border router, for every multicast group.

  • From the exterior network to the Thread network: the Primary Backbone Router (PBBR) forwards only multicast traffic with a destination matching one of the multicast groups registered by Thread devices in its network.

For the second case, a Thread Commissioner can be used as well to register allowed multicast groups on behalf of the devices.

The OpenThread stack will automatically handle the registration of multicast groups with a proper PBBR whenever they are configured in the device.

Thread Domain unicast addressing

Thread 1.2 Specification introduces the concept of Thread Domains.

A Thread Domain is a set of Thread Devices that receive and apply a common Thread Domain operational configuration. The Thread Domain operational configuration enables Thread Devices to join and participate in larger interconnected scopes even extending beyond the limits of a single Thread network. A user or network administrator may use functions of either Thread Commissioning or Thread Border Routers to set up a common Thread Domain operational configuration for Thread Devices. The Thread Devices can belong to different Thread networks or Partitions that have potentially different per-network credentials.

Thread 1.3 features

For more information about this Thread version, see the official Thread 1.3.0 Features White Paper.

Note

See Thread Specification options for how to enable the 1.3 features that are currently available in the nRF Connect SDK.

DNS-based Service Discovery

Thread 1.3 Specification introduces DNS-SD Service Registration Protocol, which lets devices advertise the fact that they provide services while avoiding the use of multicast in the discovery. The nRF Connect SDK provides the required SRP client functionality.

Transport Control Protocol

While the nRF Connect SDK has had TCP support through Zephyr (IP stack supported features), the Thread 1.3 Specification defines a set of parameters and features that make TCP more efficient for the limited IEEE 802.15.4 networks. An alternative TCP stack implementation incorporated from the OpenThread project can be enabled by users working on Thread-based TCP applications.

See the tcp.conf configuration file in the snippets/tcp/ directory of the Thread: CLI sample for an example how to enable the alternative TCP implementation.

Thread 1.4 features

For more information about this Thread version, see the official Thread 1.4 Features White Paper.

Note

See Thread Specification options for how to enable the 1.4 features that are currently available in the nRF Connect SDK.

Enhanced Internet Connectivity

Thread 1.4 introduces significant enhancements to how Thread devices can connect to the public internet. This expansion is achieved through robust support for both IPv6 and IPv4, ensuring a future-proof compatibility with the existing internet infrastructure.

Enhanced Network Diagnostics

The Enhanced Network Diagnostics added in Thread 1.4 include:

  • EUI-64

  • Thread Protocol Version and Thread Stack Version

  • Vendor Name, Vendor Model, and Vendor Software Version

  • Detailed Child information - for Thread Mesh Extenders only

  • Child IPv6 Address List - for Thread Mesh Extenders only

  • Mesh Extender (Router) Neighbors - for Thread Mesh Extenders only

  • Mesh Link Establishment (MLE) Protocol Counters

  • Vendor App URL

  • A method (“Answer TLV”) to split a particularly large diagnostic data set over multiple UDP messages

The entity collecting the Thread diagnostic information may itself be directly connected to a Thread network, for example situated on a Thread 1.4 Border Router. The collected information can then be retrieved via an authenticated, secure connection from an app or back-end to this Border Router. The entity could also be situated outside the Thread Network, collecting diagnostic information in the role of a Thread Commissioner - via a secured IPv6 link to a Thread Border Router.

Thread Commissioning over Authenticated TLS (TCAT)

Thread 1.4 introduces TCAT to enable fast and secure commissioning of large volumes of Thread devices. This feature uses an authenticated, certificate-based TLS session between the new Thread device and a commissioning tool/device. TCAT support is optional and is expected to be used primarily in commercial (B2B) markets.

See the tcat.conf configuration file in the snippets/tcat/ directory of the Thread: CLI sample for an example how to enable the TCAT functionality.

Limitations for Thread 1.4 support

Thread Commissioning over Authenticated TLS (TCAT) is an optional feature and is only supported in experimental mode by the nRF Connect SDK.