KNX IoT protocol stack architecture

The KNX IoT Point API is an application layer that runs on top of standard IPv6-based transport protocols. This separation lets KNX application semantics stay the same regardless of the underlying network, while reusing widely available IoT building blocks for transport, encoding, and security.

This page describes the protocol stack from the application down to the radio. For more details, see the KNX IoT Point API Stack introduction.

Protocol stack

The following diagram shows the KNX IoT protocol stack as used by the KNX IoT add-on, where the IPv6 transport is provided by Thread.

KNX IoT protocol stack as used by the KNX IoT add-on

Data flow

On the transmitting device, an application value travels down the stack: it is mapped to a Point API resource, encoded as CBOR, wrapped in a CoAP message, protected with OSCORE, and sent in a UDP/IPv6 datagram over the Thread network. On the receiving device, the payload travels up the stack in the reverse order, ending as a value delivered to the application.

Layers

The following sections describe each layer of the protocol stack shown above, from the KNX application down to the Thread radio link.

Application

The application layer defines the device behavior in terms of standardized KNX functional blocks and datapoints, for example a light-switching sensor or a light-switching actuator. This is the part of the stack that a KNX IoT add-on application implements. Functional blocks, datapoints, and datapoint types are described in Device and data model.

KNX IoT Point API resource model

The Point API exposes the application as a set of RESTful resources, each identified by a URI and accessed with CoAP methods (GET, PUT, POST, DELETE) or CoAP Observe for subscriptions. Datapoints, functional blocks, configuration tables, and security material are all represented as resources under standardized paths. This resource model also provides the basis for KNX S-Mode group communication, the message pattern that mirrors classic KNX group telegrams. See Device and data model for the resource structure and Group communication and discovery for S-Mode communication.

Data encoding

Structured application data is encoded as CBOR (RFC 8949), a compact binary format well suited to constrained devices; JSON (RFC 8259) is an optional alternative. Resource discovery responses use the CoRE Link Format. Using a standard encoding is what allows KNX IoT data to be used by non-KNX systems as well.

Application messaging: CoAP

The Constrained Application Protocol (CoAP, RFC 7252) is a lightweight, RESTful web-transfer protocol designed for constrained nodes and networks. It provides the request/response semantics, the Observe extension used for subscriptions, multicast support used for S-Mode, and resource discovery through /.well-known/core. CoAP runs over UDP. The KNX IoT stack provides its own CoAP handling tuned to the Point API.

Application security: OSCORE and SPAKE2+

Security in KNX IoT is applied at the application layer, so messages stay protected end to end even when forwarded by routers or border routers. OSCORE (RFC 8613) encrypts and authenticates CoAP payloads using a shared security context, and the initial context is established with Password Authenticated Session Establishment (PASE), using the SPAKE2+ handshake (RFC 9383). Security is described in detail in Security.

Transport and network: UDP/IPv6

KNX IoT uses UDP over IPv6, with mandatory multicast support at link-local, realm-local, and site-local scopes (multicast is what carries one-to-many S-Mode group messages). Because the protocol only assumes IPv6, the same device firmware concepts apply on Thread, Wi-Fi, or Ethernet.