The development of technologies in the field of software and hardware, the emergence of new communication protocols have led to the expansion of the Internet of things (IoT). The number of devices is growing day by day, and they generate a huge amount of data. Therefore, there is a need for a convenient system architecture capable of processing, storing and transmitting this data.
Nowadays, cloud services are used for these purposes. However, the increasingly popular fog computing (Fog) paradigm is able to complement cloud solutions by scaling and optimizing the IoT infrastructure.
Clouds are capable of closing most IoT requests. For example, to provide monitoring of services, fast processing of any amount of data generated by devices, as well as their visualization. Fog computing is more efficient in solving real-time problems. They provide fast response to requests and minimal delay in data processing. That is, Fog complements the "clouds", expands its capabilities.
However, the main question is different: how should all this interact in the context of IoT? What communication protocols will be most effective when working in a unified IoT-Fog-Cloud system?
Despite the seeming dominance of HTTP, a large number of other solutions are used in IoT, Fog and Cloud systems. This is because IoT must combine the functionality of a variety of device sensors with security, interoperability, and other user requirements.
But there is simply no single idea of the reference architecture and communication standard. Therefore, creating a new protocol or modifying an existing one for specific IoT tasks is one of the most important tasks facing the IT community.
What protocols are currently in use and what can they offer? Let's figure it out. But first, let's discuss the principles of an ecosystem in which clouds, fog, and the Internet of things interact.
IoT Fog-to-Cloud (F2C) Architecture
You have probably noticed how much effort is being put into exploring the benefits and benefits associated with the rational and coordinated management of IoT, clouds and fog. If not, here are three standardization initiatives: , и .
If earlier only 2 levels were considered, clouds and end devices, then the proposed architecture introduces a new level - fog computing. At the same time, the fog level can be divided into several sublevels, depending on the specifics of resources or a set of policies that determine the use of different devices in these sublevels.
What might this abstraction look like? Here is a typical IoT-Fog-Cloud ecosystem. IoT devices send data to faster servers and computing devices to solve tasks that require low latency. In the same system, clouds are responsible for solving problems that require a large amount of computing resources or storage space.
Smartphones, smart watches and other gadgets can also be part of the IoT. But such devices tend to use proprietary communication protocols from major developers. The generated IoT data is passed to the fog layer via the REST HTTP protocol, which provides flexibility and interoperability when building RESTful services. This is important in light of the need to ensure backward compatibility with existing computing infrastructure running on local computers, servers, or a server cluster. Local resources, which are called "fog nodes", filter the received data and process it locally or send it to the cloud for further calculations.
Clouds support different communication protocols, among which AMQP and REST HTTP are the most common. Since HTTP is well-known and sharpened for the Internet, the question may arise: “shouldn’t it be used to work with IoT and fog?”. However, this protocol has performance issues. More on that later.
In general, there are 2 models of communication protocols suitable for the system we need. These are request-response and publish-subscribe. The first model is more widely known, especially in the server-client architecture. The client requests information from the server, and the latter receives the request, processes it, and returns a response message. REST HTTP and CoAP protocols work according to this model.
The second model arose from the need to provide an asynchronous, distributed, loose coupling between the sources that generate data and the recipients of this data.
The model assumes three participants: a publisher (data source), a broker (dispatcher) and a subscriber (recipient). Here, the client acting as the subscriber does not need to request information from the server. Instead of sending requests, it subscribes to certain events in the system through a broker responsible for filtering all incoming messages and routing them between publishers and subscribers. And the publisher, when an event occurs related to a certain topic, publishes it to the broker, which sends data to the subscriber on the requested topic.
Essentially, this architecture is based on events. And this interaction model is interesting for applications in IoT, cloud, fog because of its ability to provide scalability and simplify the interconnection between different devices, support many-to-many dynamic communication and asynchronous communication. Some of the best known standardized publish-subscribe messaging protocols include MQTT, AMQP, and DDS.
Obviously, the publish-subscribe model has a lot of advantages:
- Publishers and subscribers don't need to know about each other's existence;
- One subscriber can receive information from many different publications, and one publisher can send data to many different subscribers (many-to-many principle);
- The publisher and subscriber do not need to be active at the same time to exchange data, because the broker (acting as a queuing system) will be able to store the message for clients that are not currently connected to the network.
However, the request-response model also has its strengths. In cases where the ability of the server side to process requests from multiple clients is not a problem, it makes sense to use already proven reliable solutions.
There are also protocols that support both models. For example, XMPP and HTTP 2.0 supporting the "server push" option. The IETF has also released the CoAP. Several other solutions have been created in an attempt to solve the messaging problem, such as the WebSockets protocol or using the HTTP protocol over QUIC (Quick UDP Internet Connections).
In the case of WebSockets, although it is used to transfer data in real time from the server to the web client and provides persistent connections with simultaneous bidirectional communication, it is not intended for devices with limited computing resources. QUIC also deserves attention, since the new transport protocol provides a lot of new features. But since QUIC has not yet been standardized, it is premature to predict its possible application and impact on IoT solutions. So we leave WebSockets and QUIC in memory with an eye to the future, but we will not study in more detail yet.
Who is the cutest in the world: comparing protocols
Now let's talk about the strengths and weaknesses of protocols. Looking ahead, we will immediately make a reservation that there is no one clear leader. Each protocol has some advantages/disadvantages.
Response time
One of the most important characteristics of communication protocols, especially in relation to the Internet of things, is the response time. But among the existing protocols, there is no clear winner that demonstrates the minimum level of delay when working in different conditions. But there is a whole bunch of studies and comparisons of protocol capabilities.
For example, the comparisons of the effectiveness of HTTP and MQTT when working with IoT showed that the response time for requests for MQTT is less than for HTTP. And when round-trip time (RTT) of MQTT and CoAP, it turned out that the average RTT of CoAP is 20% less than that of MQTT.
Other with RTT for the MQTT and CoAP protocols was carried out in two scenarios: a local network and an IoT network. It turned out that the average RTT is 2-3 times higher in the IoT network. MQTT with QoS0 showed a lower result compared to CoAP, and MQTT with QoS1 showed a higher RTT thanks to ACKs at the application and transport layers. For different QoS levels, network delays without congestion were milliseconds for MQTT, and hundreds of microseconds for CoAP. However, it is worth remembering that when working in less reliable networks, MQTT running over TCP will show a completely different result.
the response time of the AMQP and MQTT protocols by increasing the payload showed that with a small load, the delay level is almost the same. But when transferring large amounts of data, MQTT shows a lower response time. in one more CoAP was compared to HTTP in a machine-to-machine scenario with devices deployed on top of vehicles equipped with gas sensors, weather sensors, location (GPS) and mobile network interface (GPRS). The time it took to send a CoAP message over the mobile network was almost three times shorter than the time it took to use HTTP messages.
Studies have been conducted that compared not two, but three protocols. For example, performance of IoT protocols MQTT, DDS and CoAP in a medical application scenario using a network emulator. DDS has outperformed MQTT in terms of telemetry latency tested under various poor network conditions. UDP-based CoAP worked well for applications that needed fast response, however, due to being UDP-based, there was significant unpredictable packet loss.
Throughput
MQTT and CoAP in terms of bandwidth efficiency was carried out as a calculation of the total amount of data transmitted per message. CoAP showed less throughput than MQTT for small messages. But when comparing the efficiency of protocols in terms of the ratio of the number of useful information bytes to the total number of transmitted bytes, CoAP turned out to be more effective.
RџSЂRё throughput using MQTT, DDS (with TCP as the transport protocol), and CoAP found that CoAP tended to show comparatively lower bandwidth consumption, which did not increase with increased network packet loss or increased network latency, unlike MQTT and DDS, where in the mentioned scenarios there was an increase in bandwidth usage. Another scenario involved a large number of devices transmitting data at the same time, which is a typical case in IoT environments. The results showed that for higher loading it is better to use CoAP.
Under light load, CoAP used the least bandwidth, followed by MQTT and REST HTTP. However, as the size of the payloads increased, REST HTTP had the best results.
Energy consumption
The issue of energy consumption is always of great importance, and especially in the IoT system. If power consumption of MQTT and HTTP, HTTP "eats" much more. And CoAP is more compared to MQTT, allowing for power management. At the same time, in simple scenarios, MQTT is more suitable for information exchange in Internet of Things networks, especially if there are no power restrictions.
An experiment that compared AMQP and MQTT capabilities on a mobile or unstable wireless network test bench showed that AMQP offers more security features, while MQTT is more energy efficient.
Security
Security is another major issue raised in the study of the Internet of Things and fog/cloud computing. The security mechanism is typically based on TLS in HTTP, MQTT, AMQP, and XMPP, or DTLS in CoAP, and supports both DDS options.
TLS and DTLS begin with the process of establishing a connection between the client and server sides to exchange supported cipher suites and keys. Both parties negotiate sets to ensure that further communication takes place in a secure channel. The difference between the two is a slight modification that allows UDP-based DTLS to work over an unreliable connection.
RџSЂRё on several different implementations of TLS and DTLS, it turned out that TLS did a better job. Attacks on DTLS have been more successful due to its error tolerance.
However, the biggest problem with these protocols is that they were not originally designed for use in IoT and were not supposed to work in fog or cloud. Through handshaking, they add additional traffic with each connection establishment, which drains computing resources. On average, there is an increase of 6,5% for TLS and 11% for DTLS in overhead compared to communication without a security layer. In resource-rich environments that are typically located on level, this will not be a problem, but due to the relationship between IoT and fog level, this becomes an important limitation.
What to choose? There is no single answer. MQTT and HTTP seem to be the most promising protocols as they are considered relatively more mature and more stable IoT solutions than other protocols.
Solutions based on a single communication protocol
The practice of a single protocol solution has many disadvantages. For example, a protocol that suits a restricted environment may not work in a domain that has strict security requirements. With this in mind, we are left to discard almost all possible single-protocol solutions in the Fog-to-Cloud ecosystem in IoT, except for MQTT and REST HTTP.
REST HTTP as a Single Protocol Solution
There is a good example of REST HTTP request/response interaction in the IoT-to-Fog realm: . Animals are equipped with wearable sensors (IoT client, C) and managed via cloud computing by a smart farming system (Fog server, S).
The POST method header specifies the resource to modify (/farm/animals), as well as the HTTP version and content type, which in this case is a JSON object representing the animal farm that the system should manage (Dulcinea/cow). The response from the server indicates that the request was successful with an HTTPS 201 (resource created) status code. The GET method should only specify the requested resource in the URI (for example, /farm/animals/1), which returns a JSON representation of the animal with that ID from the server.
The PUT method is used when some specific resource record needs to be updated. In this case, the resource specifies the URI for the parameter to be changed and the current value (for example, indicating that the cow is currently walking, /farm/animals/1? state=walking). Finally, the DELETE method is used in the same way as the GET method, but simply deletes the resource as a result of the operation.
MQTT as a single protocol solution
Let's take the same smart farm, but instead of REST HTTP we use the MQTT protocol. The local server with the Mosquitto library installed acts as a broker. In this example, a simple computer (referred to as the farm server) Raspberry Pi serves as an MQTT client, implemented through the installation of the Paho MQTT library, which is fully compatible with the Mosquitto broker.
This client conforms to the IoT abstraction layer representing a device with discovery and computing capabilities. The mediator, on the other hand, corresponds to a higher level of abstraction, representing a fog computing node, characterized by large processing and storage capacities.
In the proposed smart farm scenario, a Raspberry Pi connects to an accelerometer, GPS, and temperature sensors and publishes the data from those sensors to a fog node. As you probably know, MQTT treats topics as a hierarchy. One MQTT publisher can publish messages to a specific set of topics. In our case, there are three. For the sensor that measures the temperature in the animal shed, the customer selects a theme (animalfarm/shed/temperature). For sensors that measure GPS location and animal movement through the accelerometer, the client will publish updates to (animalfarm/animal/GPS) and (animalfarm/animal/movement).
This information will be shared with the broker, who may temporarily store it in a local database in case another interested subscriber shows up later.
In addition to the local server that acts as an MQTT broker in the fog and to which the Raspberry Pi, acting as MQTT clients, send data from sensors, there can be another MQTT broker at the cloud level. In this case, the information transmitted to the local broker may be temporarily stored in a local database and/or sent to the cloud. The cloud MQTT broker in this situation is used to link all data to the cloud MQTT broker. With this architecture, a mobile application user can be subscribed to both brokers.
In the event of a connection failure with one of the brokers (for example, cloud), the end user will receive information from another (foggy). This is a characteristic feature of combined fog and cloud computing systems. By default, the mobile app can be configured to first connect to the foggy MQTT broker, and failing that, to connect to the cloud MQTT broker. This solution is just one of many in IoT-F2C systems.
Multiprotocol Solutions
Single protocol solutions are popular because of their easier implementation. But it is obvious that in IoT-F2C systems it makes sense to combine different protocols. The point is that different protocols can work at different levels. Take, for example, three abstractions: IoT, fog, and cloud computing layers. Devices at the IoT level are generally considered limited. For this overview, let's look at IoT layers as the most restrictive, cloud-based least restrictive, and fog computing as "somewhere in between". Then it turns out that between IoT and fog abstractions, current protocol solutions include MQTT, CoAP and XMPP. Between fog and cloud, on the other hand, AMQP is one of the main protocols used along with REST HTTP, which due to its flexibility is also used between IoT and fog layers.
The main problem here is the interoperability of protocols and the ease of transferring messages from one protocol to another. Ideally, in the future, the architecture of the IoT system with cloud and fog resources will be independent of the communication protocol used and will ensure good interoperability of different protocols.
Since this is not the case at the moment, it makes sense to merge protocols that do not have significant differences. To this end, one potential solution is based on a combination of two protocols that follow the same architectural style, REST HTTP and CoAP. Another proposed solution is based on a combination of two protocols that offer publish-subscribe interaction, MQTT and AMQP. Using similar concepts (both MQTT and AMQP use brokers, CoAP and HTTP use REST) makes these combinations easier to implement and requires less integration effort.
Figure (a) shows two request-response models, HTTP and CoAP, and their possible placement in an IoT-F2C solution. Since HTTP is one of the most well-known and adopted protocols in today's networks, it is unlikely that it will be completely replaced by other messaging protocols. Among the nodes representing powerful devices that are between cloud and fog, REST HTTP is a reasonable solution.
On the other hand, for computationally constrained devices that communicate between fog and IoT layers, it is more efficient to use CoAP. One of the big advantages of CoAP is actually its compatibility with HTTP since both protocols are based on REST principles.
Figure (b) shows two publish-subscribe interaction models in the same scenario, including MQTT and AMQP. Although hypothetically both protocols could be used to communicate between nodes at each level of abstraction, their position should be determined based on performance. MQTT was designed as a lightweight protocol for devices with limited computing resources, so it can be used to communicate between IoT and fog. AMQP is more suitable for more powerful devices that would ideally position it between fog and cloud nodes. Instead of MQTT in IoT, you can use the XMPP protocol, as it is considered lightweight. But it is not widely used in such scenarios.
Conclusions
It is unlikely that one of the considered protocols will be sufficient to cover all communication in the system, from devices with limited computing resources to cloud servers. The study showed that the two most promising options that developers use more often are MQTT and RESTful HTTP. These two protocols are not only the most mature and stable, but also include many well-documented and successful implementations and online resources.
Due to its stability and simple configuration, MQTT is a protocol that has proven its superior performance over time when used at the IoT layer with limited devices. In parts of the system where limited connectivity and battery consumption are not an issue, such as some areas of fog and most cloud computing, RESTful HTTP is an easy choice. CoAP should also be taken into account as it is also rapidly evolving as an IoT messaging standard and it is likely that it will reach a level of stability and maturity similar to MQTT and HTTP in the near future. But the standard is now evolving, which comes with short-term compatibility issues.
What else can you read on the blog?
→
→
→
→
→
Subscribe to our -channel, so as not to miss the next article! We write no more than twice a week and only on business.
Source: habr.com