Wirepas Wirepas Blog Beyond the Mesh –a reference architecture for Industrial IoT with Wirepas Mesh

March 28, 2019

Beyond the Mesh –a reference architecture for Industrial IoT with Wirepas Mesh

By Juho Pirskanen

In the Wirepas ecosystem we are witnessing more and more projects moving from performance evaluation tests and PoCs to full scale production phases. This is impacting the technical debate: shifting from comparing different radio solutions to discussing more of a system level architecture, needed additional components and how the system can be managed and monitored during operation.

The number of needed components and possible choices can be bewildering with cloud vs. edge centric architectures and multiple application / radio protocols vying for attention amongst solution architects and system designers. The effort needed to have all these pieces in place can be significant, especially if design is initiated from scratch, without clear overall architecture and understanding how to integrate existing components together. Therefore, there is a clear need to define a reference architecture to speed the transition from PoC to production. This is the goal of the Wirepas Mesh reference architecture.

Wirepas started by building a wireless mesh networking protocol that has been designed from the ground up to address the needs of massive IoT in the real-world, with unprecedented scale, density flexibility and reliability. Our investment in crafting in-house a chipset and frequency band independent wireless mesh protocol stack that includes every layer of the stack from MAC to transport layer is unique in the industry. Owning each of these layers ensures that we are uniquely placed to deliver on the needs of wireless connectivity for massive IoT.

As noted above the technical discussion is moving from component level to system level. There are many different system architectures that work, and nothing is stopping the Wirepas eco-system innovating with different approaches. However, as Wirepas we wanted to offer a reference architecture for complete end to end systems that builds on the learnings gained from multiple customer projects and leverages commonly used protocols and building blocks. The defined architecture is flexible to support different use cases and deployments with limited customization and the possibility to integrate with existing systems.

The first instantiation of the reference architecture is in our recently announced Wirepas Mesh 2.4GHz evaluation kit. To give a better overview on that architecture, this series of blog posts will step through the various elements, starting with an overview and followed by a deeper dive on the individual elements.

The overall logical view of the Wirepas reference architecture is presented below:

 

Juho blog image

 

The objective of the reference architecture is to support the largest number of use cases where:

  • Sensor data, potentially in different data formats, needs to flow from the network nodes to a gateway and onward to cloud systems, e.g. in smart building occupancy analytics;
  • Radio measurement data needs to be gathered from the network and processed in the cloud to derive location information, e.g. in asset tracking applications;
  • Commands need to flow from the cloud or locally from the gateway to network nodes, e.g. in smart lighting control applications;
  • Data or commands flow directly between nodes, e.g. in smart lighting applications.
  • System operations including performance monitoring, device management, software updates must be performed remotely from the cloud.
  • The realization of the cloud can vary from a set of servers running on-premise to IaaS or PaaS offerings from global cloud providers.

Data moving across the Wirepas Mesh network is uniquely identified through a combination of source and destination endpoints. The notion of an endpoint is similar to that of a TCP/IP port in IP networking. This allows multiple applications, or data coding formats to easily share the network transport with no effort at the application layer to de-multiplex this traffic.

In addition to application data, some diagnostics, positioning and other Wirepas stack configuration and management data can be transmitted on well-known endpoints.

If the destination address is a network sink (the radio device(s) attached to the gateway(s)) traffic is routed on the uplink using an extremely efficient cost-based routing algorithm. Once received at the gateway, running on Linux operating system, the gateway reads the data from an endpoint, and forwards the data to IP interface towards the cloud with minimum processing. As the data processing is minimised and the gateway reference software runs on Linux, there is great freedom to select cost-effective gateway hardware. To further nurture the Wirepas ecosystem we are investigating ways of making the Linux Gateway software more broadly available to the ecosystem.

In the interface between gateway and cloud we have chosen to encapsulate the data by using Protocol Buffers (Protobuf) originally developed by Google. Protobuf can run on top of any IP connection allowing to use most suitable transport option (cellular, Wi-FI, Ethernet, etc.) for the specific use case. Further Protobuf has high flexibility and coding efficiency, safety and broad support for different language with numerous open source implementations.

By default the Protobuf encoded data is published as defined MQTT topics from the gateway to a MQTT broker in the cloud. The used Protobuf MQTT topic definitions are available as part of the Linux reference gateway implementation. The data published to the MQTT broker can then be consumed by numerous different backend systems by subscribing to specific MQTT topics. MQTT is chosen due to its broad adoption, proven scalability and performance with reliability on various media.

Specific MQTT topics are provided for diagnostics and radio measurement data to allow them to be ingested by Wirepas provided backend systems such as the Wirepas Network Tool and Positioning Engine.

This reference architecture allows application data to flow to any defined MQTT broker. Different backend services with different clients can be added or removed to/from the system simply by subscribing / unsubscribing to certain MQTT topics, without impacting the gateways or actual IoT Mesh network. Different data formats used by different IoT Nodes can be supported by introducing data plugins in backend services. These data plugins can parse node specific data format to a desired format (JSON etc.) used in the management systems allowing IoT system to be a truly integrated part of operations.

This is an exciting time in the evolution of the Industrial IoT market. We are excited to have distilled our know-how and best practises into this reference architecture and share this with the community to speed the implementation of IoT systems with tangible business ROI.

If you wish to try it for yourself then check out the various evaluation kits available here.