How should you pick a protocol for your next IoT project? This article, the third and final one in a series, provides you with a few useful pointers.
This article is the last one in this series. In the first part, I described the role of protocols in IoT architecture and covered in detail four of the most widely used alternatives: CoAP, DDS, LwM2M, and MQTT. In the second part, I covered emerging protocols that address some of the weaknesses found within these four alternatives. Today, I aim to give you pointers about choosing the best option for your project. But before we get there, let’s weigh the pros and cons of a multi-protocol approach.
Do I Need to Choose?
The premise of this series is that some protocols are better than others for a specific project. There are, however, scenarios where leveraging several protocols simultaneously makes sense. The first one involves deployments spanning multiple network or interface technologies. Popular connectivity options such as Bluetooth and ZigBee do not support IP-based networking. Typically, a gateway or edge node will aggregate local non-IP traffic and forward telemetry to the relevant local or Cloud systems. Most enterprise-grade IoT gateways support multiple protocols and connectivity technologies. A good example of this is Eclipse Kura™, a platform for machine-to-machine (M2M) applications based on the Java programming language and the OSGi specification. Kura supports serial port communications, USB, and Bluetooth out of the box, as well as the GPIO/PWM/I2C/SPI interfaces found on most microcontrollers and System-on-Chip (SOCs). Plugins providing support for additional options, such as BACnet and Modbus, are available on the Eclipse marketplace or in Eurotech’s Everyware™ Software Framework (ESF), a commercially available platform based on Kura.
Another scenario where leveraging several protocols at once is unavoidable is expanding legacy deployments. Most IoT projects have to deal with existing devices and networks since the refresh cycle of operational technologies (OT) is usually longer than in other domains. Once again, gateways and protocol adapters enable the integration of legacy devices and protocols into contemporary infrastructure. This is crucial when using protocols designed before Internet connections were commonplace, such as BACnet, which lack most of the security features we take for granted today.
You could also mix and match protocols according to the specific needs of a project or deployment. This approach certainly has merits since requirements may vary a lot. For example, the peer-to-peer nature of DDS means it is well-suited to control swarms of devices, such as robots or drones deployed across a location or set of locations. A gateway could then subscribe to a specific set of DDS topics and publish specific telemetry over MQTT for aggregation at a central site, for example. However, you have to weigh the merits of this approach against one where you would use a more flexible protocol. Eclipse zenoh, for example, supports both peer-to-peer and routed communications. Its routing node even supports deploying distributed storage through a set of plugins. Consequently, it can replace MQTT and DDS in my example.
How do I Choose?
At this point, I hope I convinced you that it is in your best interest to make informed decisions about protocols. The existence of multi-protocol gateways and protocol converters does not mean that you necessarily need to leverage every option available under the sun. With that established, how should you pick a protocol for your next IoT project? In this section, I will provide you with a few useful pointers.
Use Case: Are you collecting data or controlling devices?
IoT devices are intimately tied to sensors and actuators. The former lets them observe their environment; the latter enables them to interact with it. Whether data collection or device control is the most important aspect of your use case will influence the suitability of protocol alternatives.
Publish/subscribe protocols fundamentally decouple publishers and subscribers. In MQTT, DDS, and even zenoh, clients who publish to a topic are unaware whether current subscribers are waiting for their messages. Consequently, such protocols are a good choice to send telemetry to interested parties in an efficient manner. Since the publisher only sends each message once (unless quality of service settings compel additional transmission attempts in case of delivery failures), the resource and power requirements are minimized. On the other hand, achieving the same thing by leveraging a request/response protocol such as CoAP is complex. Each client interested in the telemetry values will need to send a request to obtain them. That said, deploying caching infrastructure can lighten the burden on the device fulfilling the request.
Another issue involves clients interested in the telemetry produced by a set of devices. This involves normally sending a request to each of the devices. Protocols such as CoAP typically streamline the process by relying on multicast requests. Still, network administrators often block such requests since they can be abused to scale denial of service attacks. An alternative would be to deploy an edge node responsible for dispatching requests to the nearby devices. But this complexifies the architecture without completely removing the coupling.
Request/response protocols naturally shine whenever the synchronous execution of commands by devices is required. CoAP, for example, also implements the popular observe pattern, through which remote clients can be informed asynchronously of changes in a resource’s state over time. However, you need to be mindful of the resource constraints of your devices. Each observer maintains a separate connection, which will impact the runtime memory footprint of the code.
Constraints: What are They?
Most IoT deployments rely heavily on constrained devices. Usually, the main reasons behind this design choice are cost and battery life. Naturally, the more affordable a microcontroller or board is, the fewer resources it offers developers regarding processing power, memory, and storage. Battery life, on the other hand, is heavily influenced by the nature of the use case. Wireless communications is typically the largest item in a device’s power budget. Consequently, battery-operated devices will often rely on network protocols that optimize bandwidth usage by design.
MQTT, CoAP, and zenoh are all good examples of such protocols. All three reduce paquet size by leveraging a minimal header set and providing features that reduce the number of handshakes when using encrypted connections. Many lightweight protocols, such as MQTT-SN and CoAP, also favor UDP over TCP as their transport. The simpler, datagram-focused UDP forgoes TCP’s delivery and ordering guarantees but redeems itself with smaller packets that reduce energy and bandwidth consumption. DTLS can be used to encrypt UDP traffic. zenoh, on the other hand, can leverage several distinct transports in addition to TCP and UDP with no impact on the actual application code.
Generally speaking, IoT-specific protocols are a better fit for applications than plain HTTP, as used in RESTful services. HTTP does not have the kind of delivery guarantees that IoT protocols offer, so you should avoid it if you cannot afford to lose messages or receive duplicates, for example.
Connectivity: How reliable and available will the network be?
When building an IoT solution or deploying edge computing infrastructure, you should always assume that the network could degrade or even cut off at any time. This is another reason HTTP is a bad choice for such projects, as it performs poorly when the network’s reliability and availability are suboptimal or highly variable.
All the protocols I discussed in this series possess features that enable them to perform even in challenging network conditions. Overall, protocols that can leverage UDP or other connectionless transports simpler than TCP are better for such environments. That said, leveraging the quality of service (QoS) or delivery guarantee features in IoT protocols will typically result in higher resource and power utilization. For example, MQTT QoS level 2 ensures that each message published will be delivered exactly once to the subscribers. Behind the scenes, this involves a four-part handshake. If one of the messages (or packets, in MQTT parlance) this involves gets lost, the sender will attempt to transmit it again within a specific time window. If the network is unreliable, unsuccessful transmission attempts will rise, resulting in higher memory usage and power consumption.
Support: Does it support the rest of your software stack?
Most open source real-time operating systems and IoT frameworks support a broad range of hardware and offer built-in support for some IoT protocols, with MQTT being common. However, many protocol implementations, such as zenoh, are developed independently. When selecting an RTOS, framework, or protocol implementation, you must ensure it supports the processor architecture and specific microcontroller or processor you are targeting. Please also pay particular attention to the compiler involved. Although many projects target pure ANSI C to improve portability, not every compiler behaves similarly. In particular, proper validation of runtime behavior is key to ensuring reliable operation in the field.
Openness: How open the ecosystem is?
Open source projects offer several advantages over proprietary alternatives. However, not all open source projects are the same. Significant differences exist between independent open source projects, single-vendor open source projects, and vendor-neutral open source projects.
Independent projects are supported by communities of individuals. Typically, they depend on the continued contributions and involvement of a core team of developers to survive. The licenses used may vary. The rules governing contributions are variable and may only sometimes have been validated from a legal perspective. There is usually little intellectual property (IP) oversight.
Single-vendor open source projects are supported by a dominant organization, which dictates the project’s roadmap and possesses powers and privileges that other contributors don’t have. The dominant organization typically has its employees in key project roles. Moreover, many such projects impose onerous contribution agreements on contributors. In particular, these agreements require contributors to transfer or assign the copyright of their contributions to the dominant organization. In the last few years, this allowed some organization to relicense their open source projects under a different, non-open source license, against the will of the original contributors.
Finally, vendor-neutral open source projects are under the purview of a third-party organization, typically a non-profit foundation. Examples of such organizations include the Apache Foundation, the Eclipse Foundation, and the Linux Foundation. The mission of those organizations is to provide infrastructure and services to the projects they host. Although there are slight differences between them, they all provide a level playing field where all project contributors are treated equally. In the case of the Eclipse Foundation, the contribution agreement that developers must sign leaves copyrights with the authors of the code; contributors simply grant a license to their contribution. The Eclipse Foundation also owns the domain names, logos, and trademarks related to its projects on behalf of the community. This means no project participant can hijack a project by coopting its brand or changing its license. Moreover, all Eclipse projects undergo extensive intellectual property (IP) reviews to ensure that the licenses for their dependencies are compatible with the project’s license. The Eclipse Foundation also supports its projects in maintaining a secure software supply chain through well-maintained and validated software bills of materials (SBOMs).
Whether you pick an independent, single-vendor, or vendor-neutral open source project, ensure the community around it is open, transparent, and responsive to outsiders. In particular, the project’s roadmap must be public, and rules for accepting contributions must be documented and not favor any particular group.
Projects implementing formal specifications or standards pose a particular challenge. For a long time, industrial automation specifications and standards remained exclusive to a select minority through member-only access to the specifications and participation in their evolution. The industry saw a clear push towards vendor-neutral open specifications and standards in the last decade. Such specifications and standards are fully transparent, as their community does not impose barriers to contribution or implementation.
Sparkplug from the Eclipse Foundation is a good example of this approach to specifications and standards. Sparkplug is developed completely in the open on GitHub, fostering numerous advantages:
- Inclusive Accessibility: Sparkplug welcomes all to validate their implementations using the official Technology Compatibility Kit (TCK).
- Collaborative Evolution: Anyone can propose enhancements to Sparkplug by opening issues or pull requests on GitHub.
- Compatibility Assurance: Integrators and end users can confidently select compatible hardware and software products from the official list published on the Sparkplug working group’s website.
To broaden Sparkplug’s reach, the Eclipse Foundation submitted the specification for transposition as an international standard. Sparkplug is now known as ISO/IEC 20237. Such transpositions of publicly available specifications are only possible for non-profit organizations. This is another advantage of selecting vendor-neutral open source projects and open specifications.
Thank you for reading!
Selecting a network protocol for your IoT project is challenging, given the diverse options available and the numerous factors you must consider. However, a systematic approach considering how your needs and skills intersect with the established and emerging protocols covered in my previous two articles will go a long way. And, of course, if you need advice about IoT protocol implementations available at the Eclipse Foundation or any of our other projects in our growing collection of embedded, IoT, and edge computing projects, feel free to contact me at [email protected].
This marks the end of this series. Thank you for staying with me until the last line!
Read the other articles in this series:
—
Frédéric Desbiens manages Embedded, IoT, and Edge Computing programs at the Eclipse Foundation, Europe’s largest open-source organization. His job is to help the community innovate by bringing devices and software together. He is a strong supporter of open source. In the past, he worked as a product manager, solutions architect, and developer for companies as diverse as Pivotal, Cisco, and Oracle. Frédéric holds an MBA in electronic commerce, a BASc in Computer Science, and a BEd, all from Université Laval (Québec City, Canada).
Frédéric is the author of “Building Enterprise IoT Solutions using Eclipse IoT Technologies: An Open-Source Approach to Edge Computing,” published by Apress in December 2022 (ISBN: 978- 1484288818).
