In the third of this series of articles on KNX IoT, Bruno Johnson and Wouter van der Beek explain the fundamentals of KNX IoT devices.
Digital transformation has been one 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).
The basics
To ensure backwards compatibility with other KNX media (KNX Classic installations), the KNX IoT specification in the KNX system specifications group (3_10_5 KNX IoT Point API) describes:
• A new transport layer based on IPv6, e.g. Wi-Fi, Ethernet and Thread-based networks.
• A new communication/message protocol that allows the following communication modes:
- Point-to-Multipoint, Connectionless (Multicast).
- Point-to-Point, Connectionless.
- Point-to-Point, Connection-Oriented.
Furthermore; the new transport must use of the same data points as the existing KNX transport layers as defined in the Application Descriptions specifications (Volume 7).
Designing the new transport medium with these constraints will not change how KNX is currently applied. It still has the same approach of ETS in configuring the devices, and devices still communicate with each other by means of S-mode messages.
The technology stack
Devices must be able to communicate using IPv6, regardless of the physical layer used, meaning that Ethernet (including PoE), Wi-Fi and Thread are supported. Indeed Thread is inherently IPv6 based.
Discovery
To communicate over IP, one needs to know the IP address and port of the KNX device. To obtain this data, two different discovery mechanisms are used.
1) mDNS discovery is a protocol that uses multicast DNS (mDNS) to find devices and services on the local network without knowing their IP address. It is also known as zero-configuration, Bonjour, or Avahi. It is widely implemented for smart home devices, wireless Arduino devices, printers, speakers, network storage devices, etc. It works by sending packets to every node on the network to resolve host names and query for services. It can be used with DNS Service Discovery (DNS-SD) to browse and resolve services based on either the host name or the service. It only works for the .local top-level domain (TLD).
mDNS discovery allows discovery by:
– Serial number.
– Individual address.
– Programming mode.
2) The CoAP (Constrained Application Protocol) discovery is a special CoAP request, to discover the resources of a known host. To discover the host, a multicast request may be used, but must be supported by the server.
CoAP discovery allows discovery by:
– Serial number.
– Individual address.
– Programming mode.
– Discovery of a device that contains a specific data point.
– Discovery of a device that contains a specific functional block.
Telegram transports
The next level up is communicating over IPv6 using CoAP. This is the layer that transports the KNX telegrams from the sender to the destination. This is achieved by using URLs. The easiest way to look at CoAP is that it is equivalent to HTTP, implementing the sending of messages using the request and response paradigm, between a Client (initiator) and a Server (responder). The main difference between HTTP and CoAP is that the CoAP headers are in binary format and that CoAP works over UDP.
The verbs for issuing the messages are the same:
- GET – for retrieval of data.
- POST – for partial update of data.
- PUT – for full update of data.
- DELETE – for deleting a resource.
In addition, OBSERVE is a new function that is similar to the HTTP long poll. The Observe can be used to obtain multiple responses. For example; when the data changes, a new response is sent to the Observe request. To have the same reliability as HTTP over TCP, the CoAP protocol implemented confirms transfers. Hence the resending of the packets, when not acknowledged, is part of CoAP and therefore CoAP-confirmed requests are as reliable as HTTP over TCP. The payload of a message is determined by the content type, i.e. different formats can be supported, much like HTTP.
Payload types
The KNX IoT specification uses two content formats, each for a different function. The first is for listing of the URLs (data points/functional blocks) with which to interact, and the second for interaction with the URLs.
The Application-Link format
This content format allows the description of hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. A well-known URL is defined as a default entry point for requesting the links hosted by a server.
Typical response
An example of a typical response is as follows:
<auth/at>;rt=“urn:knx:fb.at“;ct=40,
<dev>;rt=“urn:knx:fb.0“;ct=40,
<swu>;rt=“urn:knx:fb.swu“;ct=40,
<f/rts>;rt=“urn:knx:fb.321“;ct=40
Each line contains:
– The hosted URL (between <>).
– The resource type (rt), designating what it is.
– The content type, e.g. 60 for CBOR and 40 for Application-Link Format.
This allows the client to interact with the device on a URL basis.
Interacting with a device
The URL can be seen as a data point that can be interacted with via key value pairs. The key value pairs are described with Concise Binary Object Representation (CBOR). CBOR is a binary data serialisation format loosely based on JSON. Like JSON, it allows the transmission of data objects that contain name–value pairs, but in a more concise manner. This increases processing and transfer speeds at the cost of human readability. However it opens up the documentation: define the payloads in JSON to increase human readability of the specification and have the binary format on the wire.
The data for an S-mode message can be defined in JSON as follows:
{ “s”: { “st”: “the st value” , “ga”: “the ga value”, “value”: “the value” } }
The JSON keys can be replaced with integer values to shrink the message even further in size as follows:
{ 5: { 6: “the st value” , 7: “the ga value”, 1: “the value” } }
Security
The OSCORE RFC 8613 (Object Security for Constrained RESTful Environments) standard protocol that provides end-to-end security for CoAP messages at the application layer, encrypts the application layer request/response messages between endpoints. Not only is the payload containing the value associated with a resource encrypted, but also the request method, the identifier of the resource, and the content format of the payload. This means that the application relevant data and semantics of the request/response can be protected in a way which is decoupled from the transport of the messages, whilst being lightweight in terms of overhead.
In addition to CoAP, OSCORE also uses the Concise Binary Object Representation (CBOR) for compact encoding and the CBOR Object Signature and Encryption (COSE) for encryption and key derivation structures – both designed for constrained device operations – and further compressed with OSCORE by omitting redundant information. OSCORE has built-in identifiers enabling end-to-end operations over multiple different paths, with or without IP.
The message overhead is minimal since OSCORE protects only the relevant application layer information, and the amount of data added to the size of the original CoAP message can be as low as 11-13 bytes with built-in identifiers. OSCORE has been instrumental in defining the level of overhead for lightweight communication security and outperforms state-of-the-art transport layer security.
Bringing everything together
Now all communication mechanisms are explained. KNX IoT device has a set of URLS to list which functional blocks and data points are implemented and have URLs to configure the device.
For example, there are resources (datapoints) for configuring the device. Existing concepts as Load State Machine (LSM), programming mode (PM), individual address (IA) and Group Object Table are modelled with the above-described mechanisms.
As a result, the following IETF (Internet Engineering Task Force) specifications are referenced in the KNX IoT Point API specification:
Summary
The advantage of KNX IoT is that the new technology is IP-based and can therefore be used over IT networks. It has been developed with guaranteed interoperability with existing KNX technology, and it uses the latest underlying internet-based technologies in its specification, thereby making KNX IoT secure by design.
The specification has been designed with embedded devices in mind, and the open source stack implementing KNX IoT has been shown to be quite small, running with as little as 512kB of storage memory and 96kB of memory.
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.
