Hardware, software, and data interact in an IoT solution. To use the potential, it is necessary to coordinate the three aspects mentioned. The data evaluation leads to the desired results by ensuring that the connection between the edge and cloud layer is continuous, has a strong signal, and is free of interference.
Any uncontrolled data stream interruption leads to discrepancies and errors in the data analysis. Establishing stable connectivity in an IoT solution is no small challenge, and depending on the application, the appropriate radio technologies, protocols, and data types must be selected. Well-founded know-how on both the hardware and the software side is therefore essential. The following article shows what needs to be considered in both areas – and how the right IoT platform can be found as middleware between edge and cloud.
Hardware Use Cases Require Different Radio Technologies
Very different connectivity requirements are placed on IoT devices. The range, power consumption, and data transmission rate are of particular interest. For some devices, all that is required is to communicate in an environment of less than one meter. A typical example is readers for contactless payment with credit cards, tokens, or smartphones. With other devices, it is an advantage if they communicate over dozens of meters or even kilometers. While some machines have a fixed power connection, others have to get by with a battery charge for several years.
Many different wireless communication protocols are now in use, depending on the application. In the context of IoT systems, the following three are particularly relevant:
- Bluetooth Low Energy (BLE): The energy-saving Bluetooth variant is advantageous when connecting consumer devices, as almost all smartphones support it.
- Zigbee: This is a wireless, energy-saving mesh network. The standard is proprietary and based on IEEE 802.15.4 (low-rate WPAN). The mesh structure maps complex IoT environments with many devices well.
- LoRaWAN: Devices in the ‘Long-Range-Wide-Area-Network’ can transmit messages over a distance of up to 15 km and require very little power consumption. This makes the protocol ideal for sensor data without real-time requirements in smart cities, agriculture, or monitoring vehicles.
In addition, there are variants of the standard WiFi and LTE protocols that are specially designed for IoT requirements and, for example, have lower power consumption or a more extended range than their counterparts that private users are familiar with.
Larger-scale IoT solutions include devices with multiple transmission technologies. For the data to be transmitted consistently from these to the cloud, a uniform standard must apply in the middleware compatible with the communication models on the hardware side.
Connectivity In The IoT Follows The ‘Publish/Subscribe’ Communication Model
Abstracted from the respective devices and protocols, communication within an IoT solution can in many cases be described in a ‘publish/subscribe’ model between the following three entities:
- 1. The publisher sends a message to the broker.
- 2. The broker connects clients and filters out irrelevant data.
- 3. The subscriber registers for the reception at the broker; if necessary, a filter is also used here that selects data according to specific rules.
The communication between publisher and subscriber occurs asynchronously, i.e., always mediated by a broker. This can also mediate between several instances on both sides.
Such an asynchronous communication model has various advantages and disadvantages that need to be considered concerning the connectivity of the overall solution. In particular, the benefits include the following:
- Loose Coupling: The publishers do not have to know the subscribers.
- Time Invariance: The subscriber can receive the message with a time delay; this is an important property, especially in systems with low availability. Most of the time, think of devices in sleep mode and only send data periodically or unstable network connections.
- Simple Clients: Sending and receiving require comparatively few resources, as the main load lies in the broker.
On the other hand, there are also certain disadvantages. Above all, this means that the ‘contract’ between publisher and subscriber is not understandable. Since the sender and recipient do not know each other initially, the complexity of end-to-end encryption increases. And finally, the broker can become a bottleneck – if it fails or is overloaded, the entire system can no longer communicate.
But despite the disadvantages mentioned, the asynchronous model has a clear advantage when designing connective IoT solutions. The decisive factor here is that it also makes the sometimes very complex environments with many transmitting and receiving devices manageable. Not least because of this, most IoT protocols are based on the asynchronous communication model – in contrast to the HTTP standard that is used on the World Wide Web.
Standard Protocols For Data Exchange In The IoT: MQTT, CoAP, AMQP
For communication between the fifth and seventh layers in the OSI stack – or the application layer in the TCP/IP stack – HTTP, which is established on the standard Internet, is in principle suitable. Other protocols are preferable, particularly concerning energy efficiency. In practice, the following are currently used in particular:
- Message Queuing Telemetry Transport (MQTT): MQTT was created in 1999 as part of the IBM MQ middleware and has firmly established itself as a transmission protocol in the IoT world. This is supported by the fact that all common IoT platforms contain an interface for data transmission using MQTT. The protocol is designed for limited devices in unreliable networks with low bandwidth and high latency.
- Constrained Application Protocol (CoAP): CoAP is technically based on HTTP, but thanks to the UDP substructure, among other things, it is significantly lighter and therefore better suited for IoT solutions. CoAP uses REST-like interfaces and methods such as GET and POST as usual with HTTP APIs. CoAP supports both synchronous and asynchronous communication and allows external resources to be informed of changes – comparable to the ‘Observer Pattern’ in programming. Thanks to multicast support, individual messages can also be sent to entire client groups.
- Advanced Message Queuing Protocol (AMQP): AMQP is an asynchronous message queuing protocol that is now ISO certified (ISO 19464). Compared to the protocols already mentioned, it is significantly heavier.
Which protocol is the right one for the respective project? Various criteria are considered for the selection. In IoT systems, there is a trade-off between resource requirements on the one hand and reliability, latency, and bandwidth on the other. Even if the different protocols on the individual device only make a slight difference in the power consumption, the savings are noticeable with thousands or tens of thousands of transmission points in the system.
The IoT Platform Controls The Connectivity In The Overall System
IoT platforms are the central component in the technology stack for the IoT. They represent the middleware, i.e., the link, between the devices and the software applications. An IoT platform enables connectivity; it ensures that the devices in the system are connected, and that information gets to where it needs to be processed.
To find the right IoT platform, it is first necessary to clarify which device types should be used in the IoT solution and which transmission protocols best represent them. At least the common IoT platforms support the most important protocols. Therefore, additional criteria such as support, support for the firmware in the devices, and license, operating, and development costs should be included in the requirements analysis.
ALSO READ: Enterprise Search: 3 Reasons Why It’s Fueling The Research Cycle
