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/

The post Unlocking Smart Building KNX IoT Connectivity appeared first on Smart Home World Magazine.

DSR Corporation (DSR), developer of the Distributed Compliance Ledger (DCL) for CSA, released DCL 1.2 with enhanced features for security, flexibility and functionality.

The Distributed Compliance Ledger (DCL) is a cryptographically secure, distributed network that allows IoT device manufacturers and vendors, official test houses and certification centers to publish public information about devices or classes of devices. Based on blockchain technology, allows participants to update relevant device information that is cryptographically signed. Through its decentralized nature, DCL addresses a number of issues faced by consumers, developers and manufacturers concerning information about their IoT devices. These problems can make it difficult to verify who manufactured the device, the firmware inside and the device certification details. The DCL provides a secure, tamper-resistant and public record of a device. These components allow transactions to be independently verified without the need for a central authority. The CSA DCL operates on a permissioned blockchain framework based on Cosmos SDK and Tendermint frameworks. Traditional models and centralized databases do not provide the security and immutability at the scale decentralized models can. 

Distributed Compliance Ledger 1.2

The DCL benefits from a multi-node network, individually signed transactions using pre-approved keys, with global Alliance members participating in driving the consensus protocol to ensure majority approval. The CSA DCL 1.2 release includes several new features and fixes that are important for Matter 1.2. The most significant enhancement is the support of X.509 Public Key Infrastructure (PKI) Revocation for VID-scoped PAIs (Product Authentication Identifiers), non-VID-scoped PAIs, and DACs (Device Attestation Certificates). Vendors with DCL write privileges can now submit transactions to publish the location of the CRL (Certificate Revocation List) distribution point, following the RFC5280 standard. This enables the revocation of specific device identifiers associated with a Vendor ID. Vendors can update or delete this information themselves, granting them flexibility and control over the revocation process.

To ensure a smooth transition to the new DCL version, a decentralized voting procedure was employed. This process, conducted within CSA, ensures that the update aligns with the consensus of the global Alliance members. This resulted in a successful deployment of DCL 1.2 to all DCL nodes on both TestNet and MainNet without major issues, downtimes or consensus loss.

DSR developed and maintained the DCL code open-sourced under the Apache 2 license. The DCL 1.2 release updates, in conjunction with the recent Matter release, enhance the security, interoperability and reliability of IoT ecosystems.

About DSR Corporation

DSR Corporation is a Node Admin and Trustee in the DCL Main Net meaning it owns a Validator Node (VN) and takes part in administrative approvals. DCL code was initially developed by DSR and open sourced under Apache 2 license for CSA. DSR continues maintenance of the code and implementation of new features.

About CSA

The Connectivity Standards Alliance (CSA), formerly known as the Zigbee Alliance, is a non-profit organization that develops and promotes wireless communication standards for smart homes, buildings, and the Internet of Things (IoT) devices. DSR joined CSA in 2012 and since then has been actively contributing to its work, especially to the development of Zigbee protocol.

For further information: https://en.dsr-corporation.com

The post DSR Corporation Releases Upgrade for Matter 1.2 Enhancing Flexibility and Functionality. appeared first on Smart Home World Magazine.

Wi-Fi® is set to play a key role in delivering IoT connectivity

The Internet of Things (IoT) is expanding exponentially while revolutionizing the digital landscape, and connecting technology on a global scale. By 2025, it is predicted there will be 55.7 billion connected devices worldwide, 75% of which will be connected to an IoT platform. Such unprecedented connectivity provides businesses with an opportunity to work smarter. Industries will transform to work more efficiently, an example would be, manufacturing through autonomous operations and machine learning. On a global scale, it is fueling innovation in the form of ‘smart cities’ and is empowering healthcare providers to more effectively monitor and tackle the COVID-19 pandemic.

Connecting nearly everything – from household appliances to traffic signals and beyond – requires robust and reliable connectivity. Wi-Fi will play a key role in delivering this connectivity in industrial IoT scenarios, providing high-performance, low latency connectivity that can efficiently and reliably support a variety of use cases.

A global digital haven

IoT is set to be the lynchpin of the ‘smart cities’ of the future, with research, planning, and funding increasing across the globe. In smart cities, data-driven planning is envisioned to improve the quality of life. It is used for monitoring road traffic congestion to the smart policing of crime. The number of industries benefiting from this digital revolution is vast, from agriculture and sustainability to construction.

IoT also supports businesses that are embracing the flexible working movement that has been largely catalyzed by the pandemic. With monitoring tools and the ability to be connected from any location, the success of remote working is greatly improved. Wi-Fi delivers fast, reliable, and secure connectivity that will help bring the full potential of the IoT.

Wi-Fi 6 and Wi-Fi 6E: the recipe for success

IoT spans numerous use cases with diverse connectivity demands, requiring both high bandwidth and low power, low latency capabilities. While difficult to meet these demands with a single technology in the past, Wi-Fi 6 offers the solution.

Wi-Fi 6 provides higher performance, lower latency, and faster data rates, complementing the deployment of 5G networks by ensuring connectivity indoors, in public venues and smart buildings, and in underserved areas, where 5G is far less effective. With features like Orthogonal Frequency Division Multiple Access (OFDMA), Wi-Fi 6 can better serve the diverse needs of IoT devices. Wi-Fi 6E then extends these great benefits into the 6 GHz band, which offers significant increases in available bandwidth. Because every device in the 6 GHz band must support Wi-Fi 6, there is no overhead to accommodate previous Wi-Fi generations. Wi-Fi 6E takes full advantage of the increased bandwidth, less congested spectrum, and up to seven super-wide channels in 6 GHz to deliver innovations like AR/VR, 8K streaming, and more.

Wi-Fi 6E also includes power improvements, such as Target Wake Time (TWT), which are well suited for highly congested IoT networks where many different battery-powered devices and sensors are connected to the network. This feature brings huge improvements in efficiency and battery life. Extending Wi-Fi operation into the 6 GHz band will be vital in supporting industrial IoT devices around the globe, allowing much-needed additional spectrum for Wi-Fi use. However, not every country is taking full advantage of this opportunity, which only comes when the full 1,200 MHz of unlicensed spectrum in 6 GHz is made available to Wi-Fi. If we are to meet the rising connectivity demands of the exponentially growing number of IoT devices around the world, regulators need to take action.

Clearing the path for a more secure, interoperable IoT

With IoT’s rapid growth comes a greater focus on security. New certification programs supporting Wi-Fi 6 & Wi-Fi 6E will help accelerate technology adoption and also provide strong WPA3 security and worldwide interoperability assurances that IoT devices remain securely connected.

Additionally, Wi-Fi HaLow operating in the spectrum below one gigahertz offers a longer range, low power connectivity necessary for applications including sensor networks and wearables. Its range is longer than many other IoT technology options, providing a more robust connection in challenging environments where the ability to penetrate walls or other barriers is an important consideration. Altogether, this will enable IoT vendors to bring secure and interoperable products to market, delivering the best experience for their customers.

The future

The future of IoT is set to transform the way society operates. In turn, it raises connectivity demands. Enhancements in Wi-Fi are set to deliver critical connectivity for this segment, but regulators need to recognize the current strain on Wi-Fi and make more spectrum available so Wi-Fi can continue to deliver tremendous IoT innovation.

For more information please visit, https://www.wi-fi.org/

The post The Key To IoT: Wi-Fi 6 & Wi-Fi 6E appeared first on Smart Home World Magazine.