IP carries different protocols which can also be applied to building automation. There are several reasons why IP will become the dominant protocol in the area of building automation. By joining forces, the organizations of IP-BLiS can convey the same future-oriented vision to their members, i.e. to converge towards using the same transport (IP) and the same security mechanisms, regardless of the diversity of application layer protocols or different approaches of the ecosystems. From a marketing perspective, by defining a common transport and security requirements together with one voice, IP-BLiS can represent all manufactures in the building automation domain.

No, IP-BLiS is not writing its own specification. IP-BLiS may gather requirements and relevant standards from the market - security, for instance - but each participating organization is responsible for specifying its own technology. If any gaps are identified, IP-BLiS will highlight this to the appropriate member organization.

IP has been in building protocol standards for a long time. Thousands of installs already have IP. Historically, IP was thought of as protocol specific (like BACnet/IP or KNXnet/IP) instead of IP with BACnet or KNX over it. IP-BLiS will help change that perception and conversation

Similar to what happened previously with computer networks, applications became less relevant than convergence on the same transport layer.

The goals are to establish secure IP as a solid future-proof technical solution and create materials to support this, to indicate which security requirements fits best for building IoT, and to investigate the possibility of proving co-existence of the (IP-based) technologies on the same network.

No, the goal is to have a unified message that all participating organizations endorse IP while allowing companies to decide which solution or solutions works best for their business and use cases. Participating organizations are not limited by any single market segment and their members are also active in various market segments, including building automation. This ensures that if manufacturers of different organizations approach the building automation market, their approach is unified.

Video, phone, file transfers already coexist on IP so at the technology level coexistence is automatic. Similarly, multiple building protocols can coexist on IP. IP does what it should. It is not broken so IP-BLiS does not need to "fix" it. What IP-BLiS can do is educate the market, demonstrate coexistence, and identify common tools and procedures to simplify deploying, provisioning, and securing complex building systems.

In addition to creating awareness among the different manufacturers, IP-BLiS will also agree on common requirements for network layer security so that building administrators can rely on the same requirements, regardless of which application layer is used in the building automation product connected to the IP network. Different offerings from different sources will be integrated in one building and the administrator can use without uncertainty in its security. IP-BLiS will not unilaterally decide on security requirements, but rather leverage its organizations and the regulations in different regions.

No, it is establishing co-existence on IP of those protocols. Due to IP it will be easier to use multiple protocols in a deployment scenario, avoiding specific hardware needs, and the integration can be done on application/software level. Also the same device hardware and network infrastructure can support multiple protocols. Matter is smart home focused and both can operate on the same IP network. Therefore Matter can be regarded as an additional application level protocol. Matter is creating a new standard, IP-BLiS is not. Matter is targeting interoperability, IP-BLiS is targeting coexistence. Matter is a new organization, IP-BLiS leverages existing ones.

Reduces tool and training costs for building owners and operators. Improves operational efficiency and effectiveness. Suppliers lower cost through fewer products to support and simpler system integration.

You may participate in IP-BLiS if you are a member of one of the participating organizations.

Fairhair Alliance is part of OCF which is part of IP-BLiS.

There is a liaison in place and in order to participate you must be a member of one of the participating organizations.

This is defined by the individual organizations. IP-BLiS is a market interest group.

IP-BLiS might set a common set of requirements, but the participating standards organizations will define the different technical aspects and choices.

There is a functionality and cost aspect to it. While it may seem simple to have dedicated networks for different applications because it avoids interdependencies. Running multiple networks in a building can be expensive. Especially when there is a need to have the applications talk to each other or to the Internet. Non-IP networks require gateways to allow them to talk to each other or to the internet. - Each gateway needs to be updated to the latest changes of every other application. - Each gateway needs to be kept up to date with security updates. - Most importantly, every application ecosystem needs to trust all those gateways, because it lacks end-2-end encryption. Gateways require all security credentials to perform their translation task which breaks end-2-end encryption. Another aspect is range of low power wireless networks. IP supports multiple applications in the same network. Even if two different nodes do not need to exchange information, they at least route the traffic to increase wireless coverage in the building.

You cannot deploy IP-based solutions without good security. But there are various myths that IP-BLiS can debunk. All applications will use the same IP layer, the security might be different, but that can be solved by software, the requirement level will be the same. Investigations on requirements level are being addressed (ENISA/NIST).

Yes, this enables application level convergence because all applications will run on the same IP network. Semantic translation can be a software function on the network. Each application framework has its own strengths and it will be difficult to converge to a single application framework that can do all necessary functions. This is leveraging all application protocols. The benefit is for the end user, they can choose which application layers will fit their needs and this will result in cost effective product offerings. Convergence works best in an evolution process. IP allows for that. Moving to IP will create more integration needs among the application layers. Semantic interoperability will be the next hurdle. The first goal is getting to IP, easing the way for application layers to talk to each other.

Yes, getting on the network will be determined by the network layer. Due to the sheer amount of devices there will be a need for standardized automatic onboarding procedures. IETF, WiFi, and Thread can be the basis for this. Application layers will need to adopt these mechanisms. In short, there is a difference between getting on the physical network and doing the security at the application level.

The long term goal is for gateways to be replaced with software using generic IP capable hardware. In the short term, gateways will be needed to interact with the current deployed systems as the move to IP will take several years.

Although specific responsibilities will vary by organization, IT will be responsible for the physical network and OT will work with the application layers. To be successful, both departments must work together to realize the benefit of a shared IP backbone.

IP-BLiS does not manage any open source projects. IP-BLiS is a market interest group. Some member alliances have or support open source projects addressing commonly used concepts. For example, OpenThread commissioning tools or OCF/Fairhair security tools may be used across multiple application layers.

Gateways translate between applications and can be deployed as software or a cloud application. With IP it is possible for devices to implement multiple application layers, reducing component complexity.

IP-BLiS focuses on all IP-based wireless communication protocols, hence coexistence.

Yes, for the IP-based options of KNX, BACnet and CSA.

IP-based applications coexist with other applications in the same network. Additional benefits include the reuse of IP-based infrastructure, the ease of cloud integration of different IP-based application layers, and limitless scalability. Devices on an IP-based network layer can be reached from anywhere in a building provided both sides have the necessary credentials (e.g. same security domain).

A demonstrator project is under consideration. Details will follow.

PoE fits with the general connectivity ideas of IP-BLiS and delivers power at the same time. Wired products can benefit from PoE as a simpler installation method.

Any IoT connectivity standard that supports IP is well suited. They already cover a wide range from low power to high data rate. Future IP-based carrier technologies will also be included. The benefit of IP is that the application does not require extensive knowledge about which carrier technology being used.

Yes, IP. The benefit of IP is that multiple carriers can be used without changing the application language. Certain industries may have a preference for a carrier technology which best accommodates their needs.

Yes, hardware specific gateways. Software can create the gateway.

The IP-BLiS effort is IP based and PHY agnostic. The goal is to have IP communication between the currently siloed application domains. In short, if it is IP and suitable for the deployment, it can be used.