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. Business of all shapes and sizes in commercial building automation have been asking for wireless IoT solutions to make this happen, KNX responded to this challenge by releasing KNX IoT Point API (KNX IoT).
The basics
To ensure backwards compatibility with the other KNX media, 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. WiFi, Ethernet and Thread-based networks.
• A new communication/message protocol that allows:
- The configuration of device is talking to which device.
- The support of S-mode message
- Capable of the following communication modes
- Point-to-Multipoint, Connectionless (Multicast)
- Point-to-all-Points Connectionless (Broadcast)
- Point-to-all-Points Connectionless (System Broadcast)
- Point-to-Point, Connectionless
- Point-to-Point, Connection-Oriented
• Using the same functional blocks as the other KNX transport layers (volume 7).
Note that the KNX devices without configuration are servers. E.g. the configuration of the devices will cause that the xxx will send
The Technology stack
IPV6, the IPV6 means that the devices can be communicated with IPv6, regardless of the used physical layer. Hence it means that Ethernet (including PoE), WiFi and Thread is supported. Note that Thread is IPV6 based.
Discovery
To communicate over IP, one needs to know the IP address and port of the KNX device. To obtain this data, 2 different discovery mechanisms are used.
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 discover allows discovery by:
- Serial number
- Individual address
- Programming mode
The CoAP 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. “localhost” is the address of the device itself.
CoAP discover allows discovery by:
- Serial number
- Individual address
- Programming mode
- Discovery of a device 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 Constrained Application Protocol (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 sending messages in with the request and response paradigm, between a Client (initiator) and 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
And OBSERVE, a new function that is similar as HTTP long poll. The Observe can be used to obtain multiple responses. For example; when the data changes a new response is send to the observe request. To have the same reliability as HTTP over TCP, the CoAP protocol implemented confirmed transfers. Hence the resending of the packets when not acknowledged is part of CoAP and therefore CoAP confirmed request are as reliable as HTTP over TCP.
The payload of a message is determined by the content type, e.g. different formats can be supported, similar as HTTP.
Payload types
The KNX IoT specification is using 2 content formats, each for a different function.
The listing of the URLs (data points/functional blocks) to interact with and the interaction with the URLs.
The Application-Link format
This content format allows to describe 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 URI is defined as a default entry point for requesting the links hosted by a server.
Typical response example:
<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 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 serialization 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 this 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 it can be defined in JSON:
{ “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:
{ 5: { 6: “the st value” , 7: “the ga value”, 1: “the value” } }
Security
OSCORE (RFC 8613) encrypts the application layer request/response messages between endpoints: not only the payload containing the value associated with a resource is encrypted, but also the request method, the identifier of the resource, and the content format of the payload. In this way, 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, while 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 specifications are referenced in KNX IoT Point API specification:
Summary
The advantages of KNX IoT are 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 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.Smart City,Io
Click here to read full February issue – https://www.smarthomeworld.in/magazine-february2024/
