Category: Uncategorized

The software world is 10 years ahead of the IoT world when it comes to architecture.

In the 80’s and 90’s most companies had just one IT system and software was developed in-house. This changed in the 2000’s where companies realized that they could lower their IT-costs by purchasing standard software for ERP, billing, planning etc. So to move data between the standard software solutions, integrations between them was built. Of course these integrations were vendor specific, and communication was synchronous — so if the remote system was down, then the procedure call (like a HTTP request) would fail and if you wanted to replace the remote system, a new integration was needed (vendor lock-in). In software terms, this is called a tight coupling.

Service Oriented Architecture and MicroServices

To solve the vendor-dependency problem, the software world then invented the concept of loosely coupled systems and MicroServices; A Service Oriented Architecture in which the interface and responsibility of each microservice (system) is well defined and hides the implementation details. For example, to integrate your ERP system to your task-management system, you design a generic interface between them so that you can easily replace the task-management system with a new task-management system from another vendor. Another benefit is that all the other systems that has integrations to the old task-management system, don’t have to create a new integrations to the the new task-management system. In other words: Clearly defined interfaces: One new system, one new integration.

While this solved the vendor-dependency (lock-in) problem and simplified the integration landscape, it still had the problem of being a synchronous — if a system was down then a retry-policy and/or error-handling needed to be put in place. Also, updates to systems needed to coordinate with every other dependent system in order to avoid downtime.

Message Queues — asynchronous communication

So the software world introduced Queues. Now, every time a system sends a request/message to another system, it will put it into a queue. This de-couples the systems completely and allows for asynchronous communication: The sending- and receiving system does not need to be online at the same time. Suddenly, taking down a system for maintenance could be done at any time and no service would be interrupted or no data would be lost. When the system came back online, it would then continue emptying the queue from where it left off.

IoT-architecture today

Most IoT solutions today are vertical: They have their own proprietary:

• Sensors
• Connectivity solution
• Analytics system or application
• API

They are integrated directly into their customers systems — that is, their APIs are used/invoked directly. In software terms, this is called a tight coupling.

You can probably see where this is going…

The IoT architecture of tomorrow

Building owners are realizing that verticle IoT-solutions does not scale and have too many drawbacks. Surveys also shows that. Think about it: It does not make sense to have multiple motions sensors in each room (alarm system, lighting, room-usage%, adaptive cleaning). Or multiple temperature/CO2 sensors… That’s not all, building owners must have multiple connectivity solutions, one for each vertical IoT-solution.

Obviously, having ONE SINGLE motion sensor (or temperature/CO2 etc.) and use that output for all data-consuming solutions (alarm system, lighting, room-usage%, adaptive cleaning), have a long list of benefits:

• One-time installation for sensors
• Simpler integrations (only interface/integration to data-consumers change)
• Save batteries (no multiple motion/temp/co2 sensors)
• No need to replace the entire sensor-system if vendor goes bust
• Sensors are commodities — replace with any vendor
• Covering your building with wireless IoT-connectivity only need to be done once
• You own and control all the data generated from the sensors
• Enables innovation: Extremely simple to build a find-me-a-meeting-room-now app (motion sensors are already there)
• No vendor lock-in — just tell your adaptive-cleaning-vendor to use your existing sensors
• Environmentally friendly: Re-use or re-purpose old sensors (today you can’t re-use a proprietary motion-sensor from one vendor and use it in another vendors system)

What about queuing — asynchronous communication?

Scholars agree (and Xerox PARC (for you history nerds)) that the future of IoT networking belongs to Content-Centric Networking (CCN). In a CCN network, the endpoints communicate via name-based data instead of IP-addresses. The object of encryption is the data, not the connection. Routers (called Content Stores) in a CCN networks caches the data (message queuing) so that data-consumers can retrieve it at any time. This enables wireless offline devices to retrieve commands/data when they wake-up. This is true asynchronous communication. CCN networks, like IP networks, has no single point of failure.

Z-Mesh, an Open Source, CCN-inspired IoT networking protocol, is solving the problems discussed in this article today. Z-Mesh combines the naming-scheme and publish/subscribe feature from MQTT with the CCN features and is thus familiar to use. Anyone can build devices, routers and device management systems. If you want to help build on this vision and eco-system, please contact me.

Aer Networks is a company that delivers Z-Mesh IoT sensors, wireless forwarders and device management software and is sponsoring the Z-Mesh initiative. Please contact me if you are interested.

Scaling is the greatest problem with IoT and Interoperability is the cause.

Before describing how to achieve interoperability on heterogeneous networks, lets start with defining a few requirements for what an IoT must support:

• Multicasting: Events must be sent One-to-Many in a pub/sub fashion
• Heterogeneous networks: Must support TCP/IP, Wireless, Cellular
• Content naming: Consumers must be able to access any content (Network effect)

Multicasting and Multihoming

The Z-Mesh architecture seamlessly handles the dissemination of content to a single consumer or to a group of consumers. Z-Mesh manages all the interfaces over which data are sent or received with components named Faces. Each Face can be connected to higher layer entities, such an application, a physical network interface or even a virtual link, such as a TCP/IP connection. As a result, Z-Mesh supports multicast communications out of the box.

Furthermore, Z-Mesh overcomes the well-known problems that IP architectures presents with multihoming. In fact, since Interest routing (request for data) is based on the Content Name, Z-Mesh works out of the box in heterogeneous network environments with multiple channel technologies (wireless, wired, TCP/IP, Cellular) and is capable of aggregating Interests received from different faces, so that only one Interest per content is sent over a shared communication link. Furthermore, nodes with multiple network interfaces, called Content Stores, are also capable of caching. When a Data packet is sent back to the consumer, Z-Mesh leaves a copy of the message in the Content Stores of all nodes along the reverse Interest path. Popular content is then automatically made available close to its consumers.

Heterogeneous networks

IoT encompasses a wide range of devices, from small sensors to complex industrial equipment. Supporting heterogeneous networks allows IoT systems to connect and integrate these diverse devices, ensuring seamless communication and data exchange.

IoT deployments often need to scale up or down, and adapt to changing requirements over time. Heterogeneous network support provides the flexibility to incorporate new technologies, protocols, and devices as they emerge, without having to completely overhaul the existing infrastructure.

IoT systems often need to integrate with various legacy systems, enterprise applications, and cloud platforms. Heterogeneous network support enables seamless interoperability, allowing IoT devices and systems to communicate and exchange data across different platforms and technologies.

By supporting multiple network technologies, IoT systems can leverage redundant communication paths and failover mechanisms, improving the overall reliability and resilience of the system. Heterogeneous network support allows IoT systems to select the most appropriate network technology for each use case, optimizing performance, energy efficiency, and cost-effectiveness.

Content Naming

In order to achieve interoperability and scale (the Network Effect), each piece of content must have it’s own unique Content Name.

So how do we achieve interoperability?

Metcalfe’s law when applied to IoT, says, the value of an IoT network (solution) is proportional to the square of the number of addressable pieces of Content Names. That is: If all Content Names can be retrieved by any Consumer, you have maximum value.

Unique Content Names (addressing) allows Content Producers and Consumers to be properly routed and connected within the network, enabling communication and data exchange between them. Without unique Content Names (addressing), the network would not be able to effectively route and deliver Content, limiting the overall connectivity and value of the network.

As the network grows, the number of connected devices and systems increases exponentially. Robust addressing schemes (Content Naming) are necessary to accommodate this growth and ensure that the network can scale effectively, maintaining the network effect as the number of connected entities expands.

Unique Content Names (addressing) enables interoperability between different devices and systems within the network. This interoperability is crucial for realizing the full potential of the network effect, as it allows diverse entities to seamlessly communicate and collaborate.

Unique Content Names (addressing) facilitates the management and control of the network, allowing administrators to monitor, configure, and troubleshoot individual devices or systems. Effective network management is essential for maintaining the stability and reliability of the network, which is a key factor in achieving the network effect.

Conclusion: Use Z-Mesh

The Z-Mesh IoT protocol, being an Information-Centric Networking architecture, allows for interoperability and scale because it supports Globally Unique Content Names (addressing) on heterogeneous networks.

Quotes from the 2024 paper: Internet of Things (IoT) Advisory Board (IoTAB) report

Quote:

By fostering symbiotic relationships and co-opetition among participants, platform-based IoT business ecosystems drive innovation, monetization, agility, and scalability through open architecture, governance, and network effects,45 as proven by trillion-dollar platform giants.

The Internet facilitated the development of digital platform business models. A platform-based business model “creates value by facilitating exchanges between two or more interdependent groups, usually consumers and producers. To make these exchanges happen, platform-based solutions harness and create large, scalable networks of users and resources that can be accessed on demand. Platforms create communities and markets with network effects that allow users to interact and transact.”

…

Platform-based IoT business ecosystems are comprised of complementary partners, resources, standards, and tools. These have long been advocated by business scholars for their proven ability to fuel economic value by leveraging scalable digital platforms as the foundation for dynamic and interconnected business networks. By fostering symbiotic relationships and co-opetition among participants, platform-based IoT business ecosystems drive innovation, monetization, agility, and scalability through open architecture, governance, and network effects, as proven by trillion-dollar platform giants.

Orchestrated business partnerships

Partnerships are critical to the development of the IoT-enabled economy. End-to-end IoT solutions across industry ecosystems are inherently complex, and involve multiple companies, technologies, and standards. By forging IoT business partnerships with complementary stakeholders, organizations can leverage each other’s strengths to develop integrated solutions and accelerate the creation of data ecosystems.

Orchestrated platform-based business ecosystems bridge industries

While existing large-scale platforms have excelled in various domains, there remains a noticeable void in multi-stakeholder collaboration platforms across industry ecosystems. One of the main strategies for achieving hyperconnected growth is to encourage platform-based business ecosystems that link IoT value chains.

Findings:

• IoT systems depend on chips sourced through vulnerable global supply chains.
• Establishing trust in IoT requires a multi-dimensional ecosystem perspective, extending beyond cybersecurity and privacy.
• Privacy concerns undermine trust in IoT and are a significant barrier to widescale adoption.
• IoT cybersecurity concerns are a major barrier to widescale adoption.
• IoT modules built by Chinese companies dominating our market poses a serious security and economic risk.
• Interoperability is a key challenge for IoT across multiple industries.
• A variety of connectivity challenges are hindering IoT adoption, operation, and scaling.
• The IoT-enabled economy is unlocked and accelerated with platform-based business ecosystems, which require multi-stakeholder collaborative partnerships to be successful.
• Equity in access, opportunities, benefits, and outcomes is necessary for the sustainable integration of IoT into all aspects of the national economy and civil society.

Interoperability

A significant barrier is the inability of devices to communicate with each other or with the broader enterprise, legacy systems, and operations technology systems. In some cases, the lack of interoperability is caused by a lack of standards and protocols. In other cases, there are multiple competing standards as each solution provider creates “walled ecosystems”.

Complexity and Integration

IoT consists of sets of disparate technologies offered by a fragmented ecosystem of hardware suppliers, software platforms, and connectivity service providers. It is not a “one size fits all” solution, and components must be assembled to create a solution that meets the specific requirements. In addition, IoT implementations often require integration with existing systems and infrastructure. Integrating IoT devices and platforms with legacy systems is a significant barrier, costly, and requires technical skills that are in short supply.

These issues create “siloed” data trapped within a specific device or vendor’s ecosystem. As a result, integrating systems to enable communication and data exchange is complex and costly, requiring additional middleware and custom integration.

This inability to integrate IoT with existing legacy and modern systems hinders innovation and the full benefits of interconnected, automated systems.

Cost savings

Buildings: The lack of interoperability in IoT systems prevents significant cost savings and revenue opportunities. For example, in [USA] healthcare, it could result in $35 billion in missed annual savings in the U.S.123 In renewable energy, achieving interoperability could save up to $10 billion by reducing transaction costs and increasing efficiency. Without it, there may be $59 billion in lost opportunities from innovative energy applications not being deployed in buildings.

Transportation: In transportation and logistics [USA], improved interoperability and real-time data sharing could reduce global freight emissions by 22%.

Vendor lock-in

The lack of interoperability in IoT creates vendor lock-in and switching barriers, resulting in a fragmented market of “walled garden” solutions. These solutions only work with a limited set of compatible equipment, reducing choices and forcing buyers to stick with specific vendors. IoT technologies based on proprietary standards do not work with other systems, compelling buyers to continue using the same vendor and its partners, often leading to higher costs, fewer innovative features, and limited capabilities. Migrating from these systems to other lower cost or more innovative alternatives is difficult and may require significant switching costs.

Learn from the history if the Internet

The Internet connected people with people, businesses with businesses, and people with businesses. In doing so, the Internet facilitated the development of digital platforms and business models and services enabled by connectivity.

A platform-based business model “creates value by facilitating exchanges between two or more interdependent groups, usually consumers, partners, and producers. To accelerate adoption, platform-based solutions harness and create large, scalable networks of users and resources that can be accessed on demand. Platforms create communities and markets with network effects that allow users to interact and transact.”

IoT as foundation for the digital economy

To advance the IoT digital economy, it is crucial to build a foundation of connectivity and IoT platforms that promote interoperability, digital transformation, and collaboration across business ecosystems.134 History shows that platform-based economies accelerate the evolution of such ecosystems.

Multi-stakeholder IoT partnerships enabled by platforms are key to accelerating widespread adoption and contributing trillions to our GDP.

Source: https://cloud.aernetworks.com/s/PEAmrSHqGi8oFYG

TLDR:

1. Interoperability is key
2. TCP/IP is not an option.
3. Municipalities MUST invest in truely open systems (no part can be patented)
4. Constrained low-power battery-driven devices are hard to support
5. Open system allows third-parties to innovate

Link to paper: https://cloud.aernetworks.com/s/4STReMBdYET96rr

Quote:

Interoperability and Open Standard Development
With the popularity of IoT devices, many IoT protocols and standards have been developed. In contrast to ordinary computers, IoT devices are normally constrained when it comes to memory space and processing capacity. In addition, IoT devices might be deployed where there’s limited or no access to continuous power supply, which means that they need to operate under power supplied from batteries or small solar panels. As a consequence, power-efficient communication protocols with small memory footprints and limited demands on processing have been developed to support IoT devices. Traditional TCP/IP protocols haven’t been designed with these requirements in mind.
…
Standard protocols are important to guarantee interoperability of different IoT devices.
However, using open standards doesn’t automatically result in open systems. In our context, an open system means an integrated open IoT infrastructure solution for smart cities, providing access to open data and APIs for cloud services. In many cities, that infrastructure will be paid for, at least in part, by the city authorities using public funding. To motivate this investment, and get the most benefit for society, we argue that any smart city IoT infrastructure needs to be a truly open system, where equipment from many vendors can be used, and where the generated data can be more or less freely used by anyone to develop new services, based on low-level as well as processed sensor and IoT data. This kind of system will maximize innovation in the IoT domain, much as the Internet has done for information and communication services. Many current IoT systems — for example, for air quality monitoring or the smart home — are either incomplete systems with limited functionalities (that is, in terms of sensing, storage, and analytics), or are closed, proprietary systems dedicated for a particular task. The latter are vertically integrated systems, sometimes called stove pipes or vertical silos, which can’t be combined or extended easily with third-party components or services. The result is that once invested in a particular system, you’re locked into that vendor’s system. Vertically integrated systems are particularly problematic for the public sector, because this prevents fair competition in public procurement and is less suitable for large-scale data sharing.
Patrik Fältström (7) argues similarly that market forces work against open interoperability, specially in the IoT domain where, for example, a smart lighting system from one vendor only works with light bulbs from the same vendor. Systems are designed as end-to-cloud-to-end, where the cloud part is vendor-controlled with limited possibilities for third parties, and where the IoT devices often speak proprietary protocols to the cloud. Fältström argues that this lack of interoperability severely limits the market growth (for example, with smart light bulbs). Also, the dependence on a cloud service might render the device non-functional, should that cloud service for any reason, temporarily or permanently, disappear.
Instead of these stove pipes, we need horizontally designed systems with well-defined interfaces and data formats that can unleash the potential of open data, and that enable third parties to independently develop new applications and services, possibly combining several data sources. Providing open data has huge potential for innovation in digital applications and services, resulting in very large economic values. These interfaces (APIs) through which the IoT data can be accessed at multiple levels of refinement — from raw data directly from sensors, to highly processed data — also need standardization. The challenge is to provide an open system that lets users access the open data and cloud services without being locked by a particular platform. The open system should also allow third-parties to innovate based on the open data and open APIs.