The e-magazine for KNX home & building control

Integration of Disparate Systems in Commercial Buildings: IP-BLiS promotes common best practices

As building control technology converges with IT, the market interest group, IP-BLiS, is recommending the consistent use of Internet Protocol (IP) across the entire network. Yasmin Hashmi looks at the rationale behind this and discusses the common best practices proposed by IP-BLiS for providing secure, multi-standard, IP-based harmonised networks.

Until recently, different technologies used in commercial/public buildings, such as elevators, security systems, power, lighting, HVAC etc, have developed in silos, with their own control protocols. In an increasingly interconnected world however, it is inevitable that these technologies will converge with IT systems and require a common, secure, IP backbone. Hence, organisations such as BACnet International, CSA, DALI Alliance, KNX Association, Open Connectivity Association and Thread Group have got together to form a market interest group called IP-BLiS (Internet Protocol for Building & Lighting Standards) in order to provide guidance, avoid/overcome integration problems and make building automation more IT friendly.

IP-BLiS is a market interest group advocating smarter, greener and safer buildings through the best technology

IP-BLiS is not a new entity, but a collection of existing ones that started working together in 2020. It does not write new technical specifications, but wants to contribute to the development of smarter, greener and safer buildings by making the best technology known and understood, and collecting market feedback on behalf of the participating organisations. The common goal is to make commercial buildings more responsive to the needs of users by promoting a secure, multi-standard, IP-based harmonised network solution.

Currently, there are three main areas of focus for IP-BLiS:

• Common Best Practices – analysing recommendations and promoting best practices.

• Commercial Building Lifecycle – creating a view of the benefits for the different actors across the lifetime of a building.

• IP-BLiS Cybersecurity Landscape – communicating the regulations that vendors will need to meet and how the IP-BLiS recommendations will help the market.

In this article, we will look at the first item, namely Common Best Practices.

First things first – why use IP networks?

As already mentioned, integrating disparate systems in buildings is a challenge, compounded by the fact that such technologies may be incompatible if not configured properly. Indeed, even multiple systems using the same field bus (device network) technology are sometimes deployed in a building, because of difficulties in managing integration. This adds to installation costs and complicates interoperability.

IP-BLiS suggests that more advanced building automation solutions should avoid this by having a clear separation of networking technology and application protocol. With IP-capable technology being available for all classes of device, from very constrained devices such as battery-driven or energy-harvesting switches, to high-performance hardware such as routers, IP networks are the ideal networking platform for building automation applications and for avoiding some of the traditional integration hurdles.

A common misconception is that if IP is being used, everything has to be Internet-based, but that is not the case. As a basic data communication method, whether the network is connected to the Internet or not, IP is very capable and easy to deploy because it is a global standard and many IP infrastructure components are already available from the IT industry. IP networks are known to be very powerful and versatile, as there is usually more than one way of addressing a specific use-case or solving an issue.

However, not every network is professionally managed by an IT department, and this can be challenging if things are not configured correctly or if network issues arise. Fortunately, help is at hand thanks to building control and networking standards such as BACnet, CSA, DALI, KNX IoT, OCF and Thread, which can automate many critical configuration tasks and thus avoid conflicts. This is the technology that IP-BLiS is promoting – it is what its participants are using and what they want to share more widely.

Participating building control and networking standards organizations in IP-BLiS.

Common Best Practices

In order to establish and promote the best practices, IP-BLiS conducted an analysis among all its participating organisations so that it could identify common technology choices and practices. This covered different areas of building control network management including device addressing, service discovery, security, physical layer support, and infrastructure requirements.

Summary of common best practices for different areas of building control network management.

Let’s have a look at some of these areas in a bit more detail.

Device addressing

Fortunately, consensus in networking technology was fairly easy to reach as all of the participants made similar choices to ensure that their technologies are IT- and IP-friendly for easy network management. All agreed that IPv6 should be used in modern networks to ensure scalability, performance and availability of a large enough multicast address space for group communication. IPv6 was developed because with IPv4, the world was running out of individual addresses for devices in the global Internet. In commercial building automation, each building can include hundreds of devices such as actuators, sensors and switches, so just imagine how many addresses are needed globally! Using IPv6, the need for network address translation (NAT) can usually be avoided because all nodes get unique addresses.

Nonetheless, there is also recognition that a lot of IPv4 networks already exist in buildings. IP-BLiS says that these must also be supported through NAT64 – a form of network address translation – so that IPv6 products can communicate with existing IPv4 components. This ensures that a building currently using IPv4 only can still add IPv6 based technology from the participating organisations without the need for bigger changes to the current configuration. In fact, if the building automation technology fits in a single network segment, no additional router configuration may be needed at all when integrating with the building’s IPv4 network.

Addressing conflicts

When it comes to configuring IP addresses, port numbers and multicast/group addresses, IP-BLiS recommends technology that will do this automatically rather than manually, thus avoiding conflicts as a result of mistakes, duplications or things being poorly-managed. This is consistently supported by the IP-BLiS participating standards, unless such resources are already registered to the respective application with IANA (Internet Assigned Numbers Authority) to avoid double use.


In terms of network infrastructure, a common choice was that while Internet services should be supported, permanent access to the Internet should not be a requirement. And again, if Internet access is necessary, then ideally, it should be IPv6 based (although NAT64 for IPv4 networks can also be used to avoid the need for changes in the existing IT network). Independence from the IPv6 prefix distributed by the Internet provider can be accomplished by the use of unique local addresses based on a ULA prefix. Such prefixes can be automatically assigned with prefix delegation (DHCP-PD) on the local network. Many IPv6 routers support prefix delegation out of the box. If the larger building network is IPv4-based, then the IPv6 router of the building automation subnet can take that role.


As stated above, it is important to note that none of the IP-BLiS participating standards strictly requires Internet connectivity, allowing for critical environments where it may be preferred to isolate the building automation network from the public Internet. However, if a system is required to connect to the outside world, IP-BLiS participating standards provide options to use well-proven security concepts of the Internet. A fundamental security requirement followed by all participating organisations is the use of two security layers for wireless networks, namely network layer security and application layer security. Even the most constrained building automation devices, such as wireless sensors and actuators implement this concept.

Very much like in IT networks, all devices in an Internet-connected network should be protected with a firewall. Many concepts known from IT networks also apply to sensor-actuator networks. A guiding principle is that any connection must be initiated from the inside to the outside, not the other way around. Once an outside connection has been established and both sides of the secure communication channel are successfully authenticated with well-known IP technologies such as TLS or DTLS handshake, there may be a long-standing connection to enable remote service or data reporting.


In traditional non-IP building automation technology, gateways are needed for Internet connectivity, but this has the disadvantage that end-to-end security is lost. This can limit the use-case of building automation networks significantly, especially considering that the weakest point often determines the quality of the overall system. Therefore, IP-BLiS promotes technology which applies the same stringent security requirements for all devices in a building. Professionally-managed gateways may still offer another layer of service or access control, provided they are on top of an already-secure network.


By promoting a common IP architecture for different building control products, IP-BLiS aims to improve interconnectivity, facilitate easier integration and bring about a smoother convergence with IT. Common choices and best practices are an essential ingredient in making more complex and feature-rich building automations systems sustainable and manageable. Products following these concepts are about to come onto the market, and IP-BLiS will continue providing information on their progress.

Participants in alphabetical order [GU1]

Share on facebook
Share on twitter
Share on linkedin


JUNG area / line coupler

JUNG area / line coupler
The JUNG area / line coupler connects two KNX lines while retaining electrical isolation. Across publicly accessible areas, such as corridors ...