In the sixth of this series of articles on KNX IoT, Bruno Johnson and Wouter van der Beek explain the how to use Thread for KNX IoT.
Digital transformation has been one of the main strategy topics on company board meeting agendas for the last few years. The opportunity to develop digital services from cloud-based applications requires Internet protocol (IPv6) based network connections to edge devices that become the customer interface. Businesses of all shapes and sizes in commercial building automation have been asking for wireless IoT solutions to make this happen, and KNX Association responded by releasing KNX IoT Point API (KNX IoT).
Thread introduction
As already explained in our article ‘KNX IoT: Part 2 – the advantages of Thread‘, Thread is an IPv6 based meshed network. In this article we will explain Thread in more technical detail, including how it can be used for KNX IoT devices.
The Thread meshed network contains various Thread networking roles, as shown in Figure 1.
Thread border router
The Thread Border Router (BR) is the network entity that connects the Thread network to the wider IT network. This entity is needed when the KNX configuration software tool, ETS, is running as a PC application on the IT network. It is also needed for other network communication, for example using the KNX IoT Router (see Part 5 of this series) to connect KNX IoT to other KNX devices.
The Thread Border Router is a standard networking function. This product can have multiple aspects and can be based on networking equipment, for example, Thread can be an extension of a Wi-Fi Router. Also, other executions are possible, for example, integrating it with the application domain. Note that Thread allows for multiple border routers to be used in a Thread network, for redundancy.
This allows for Thread networks to be partitioned either intentionally or unintentionally (should a Router fail for some reason), without interrupting operation.
Next to the Border Router, Thread specifies device types that can assume the different network roles. To explain the different device types, one needs to understand the Thread networking roles first.
Router role
The Router node is the network entity that routes IPv6 messages between Thread nodes, either other Router nodes or End Devices. This is a networking function of the Thread network.
End Device role
The End Device role is a leaf node. From a networking perspective, it only talks to its parent (a Router). These End Device roles are the REED (Router Eligible End Device) or the End Device.
Leader role
The Leader is a specific role of a Router node. The first Router node on the network will become a Leader. The Leader is responsible for making network decisions, for example, the Leader can promote Router Eligible devices to Routers to improve connectivity if required. There is only one Leader in a Thread network. If the Leader fails, another Router will become the Leader. All routers store the network data, but only the Leader can make changes to it.
REED (Router Eligible End Device)
The REED device can have the Thread Router role or Thread End Device Role, and will dynamically upgrade itself to a Router from an End Device as the Thread network expands, and conversely, downgrade itself from a Router to an End Device as the network contracts. The REED device is very useful, as it allows the Thread network to self-manage.
ED (End Device)
This device only supports the End Device role. The ED device can only connect to a device with a Router role or the Border Router.
SED (Sleepy End Device)
This device only supports the End Device role, but has the capability to go to sleep. The main difference is that when the device goes to sleep, it detaches from the Thread network (i.e. no radio communication). The parent Router will cache the incoming traffic for such a device, so when it is active again, it will receive the incoming traffic.
The SED device can only connect to a device with a Router role or the Border Router, and will automatically switch parent if it loses connectivity.
Mesh Extender
This device is not mentioned earlier, but it is actually a line-powered Router or REED device. The purpose of this device is to extend the reach of the mesh network, i.e. it can be placed where a direct network link is weak. This device can be a pure Thread device, meaning no application functionality is implemented on the device.
Implications
So how do these Thread roles apply to KNX IoT devices?
KNX IoT devices that are Thread-based will have to be implemented as REED, ED or SED devices, otherwise they will not be part of the Thread network. This would seem to be a separate decision to what the function of the KNX device should be, but is it?
All KNX IoT devices will implement a set of functional blocks: i.e. the purpose of the device. The hardware selection to make up the purpose of the device will depend on whether the device is to be line-powered (always on) or powered by low-energy sources (such as energy harvesting or battery-powered). The general rule is that if the device is line-powered, one should build a REED device. For all other sources, one can build an End Device and even a Sleepy End Device if the function of the KNX IoT device can be made with hardware that consumes low power or can be periodically turned off (i.e. not consuming active power).
Examples of KNX IoT EDs and SEDs
For example, if a device only sends out data periodically, such as a temperature sensor, and if the temperature sensor data acquisition is low-power, one can create a SED. If the data acquisition of the sensor is continuous, then a SED can still be made (in order to avoid additional power consumption used by the RF transmitter), but it could be an ED device.
For devices that have incoming requests and require a timely response, the device can be an ED or a REED.
For devices that have incoming requests, but acting upon that request will be slow, such as an air-quality sensor, these can be executed as a SED.
Devices that require line power due to their additional hardware, should be built as a REED. Examples of this are lighting fixtures.
Summary
Thread enables KNX IoT Devices to be developed in such a way that suits the required power budget. The choice of REED, ED or SED should be made according to the power requirement of the peripherals that make up the function of the device.
Bruno Johnson and Wouter van der Beek are the CEO and COO respectively of Cascoda Limited. Cascoda is a communications company that manufactures secure IoT semiconductor radios and modules, and leads the development of secure IoT communications standards for smart building and smart city. Its products solve range, reliability, security, power and scalability issues for industrial and commercial IoT through patented innovations and the latest most secure standards, all integrated into inexpensive ultra-low power IoT modules.
