Protocol Options and Considerations | Introduction to IoT Architecture

It has been 18 years since the term "Internet of Things" was coined in 1999. The term IoT is currently gaining momentum in the IT industry, with hardly a day going by without hearing about it. So, what exactly is IoT? Let's take a look at the true nature of IoT.

Protocol options and considerations

This time, I would like to introduce specific types of protocols and transfer methods.

Four IoT architectures have emerged to date, and there are several communication protocol options available.

So, what is the best protocol in the context of IoT? The choice depends on the situation and requires consideration of various trade-offs.

Below, we will provide a rough overview of the characteristics of representative protocols that frequently appear in the context of IoT, and then consider how they can be applied to systems.

HTTP

HTTP is one of the most well-known protocols.

• Simple and versatile
• High overhead
• Easy to reuse existing systems

Its features include its use of TCP, its simplicity, and its versatility.

All HTTP requests and responses must include message headers, which contain information necessary for each HTTP message to be processed.

In the context of IoT, some aspects of the HTTP specification, particularly the cost of creating and transmitting message headers, make it difficult to avoid HTTP.

MQTT

Next is MQTT, a lightweight protocol that uses pub/sub communication and is a protocol that is relatively often adopted in IoT systems.

MQTT has the following features:

• Low overhead
• Messages delayed at one time are limited to 256 bytes
• Pub/Sub type communication
• QoS (guaranteed delivery)
• There are large differences in functionality between products

MQTT is lighter than HTTP and is suitable for situations where the data sender has limited resources.

To perform MQTT communication, a server called an MQTT broker is placed between the client that sends the data and the service that actually processes the data.

It is possible to distribute the processing of large numbers of small-granularity tasks that occur by preparing a large number of subscribers.

There are several QoS levels to choose from depending on the situation, and delivery guarantees can be set between clients and brokers.

Low-layer communication methods

IoT systems may also use lower-level protocols than HTTP or MQTT as even lighter protocols.

• TCP
• UDP

One of them is TCP.

TCP is a protocol that emphasizes reliability and is the basis for HTTP and MQTT. TCP uses a method called a three-way handshake to ensure the reliability of data transfer, but this increases the number of communications.

In contrast, UDP sends data to the other end and then leaves it there, meaning that while data transfer is less reliable, it allows for very lightweight communication.

It may be used when lightweight is a priority, even if some data is lost.

Trade-offs and choices

Now let's consider what protocols can be used in what situations.

We will also consider points around the protocol that require unique ingenuity.

• Communication quality
• Communication volume (fee)
• Machine Resources
• battery
• Mission-critical
• Real-time
• Security

Communication quality

In particular, the "Device to Cloud," "Using Gateway," and "Using Mobile" patterns often involve the use of cellular networks.

Depending on the quality of the cellular connection you use, some data loss is expected. If the data you are transferring is important, you will need to cover the loss somehow.

For example, HTTP requires the implementation of a mechanism to detect data loss and perform retries. Also, if communication quality is low, communication delays can impair real-time performance, and a buffering function may be required.

Communication volume (fee)

There may be cases where you are using a cellular line or want to use a lightweight protocol to reduce communication volume (fees).

If you also need to ensure real-time performance, you will probably need to consider MQTT or a proprietary protocol.

If you can compromise on real-time performance, you could consider buffering the data to a certain extent, compressing it, and then sending it in batches.

Machine Resources/Battery

This should be taken into consideration especially in the "Device to Cloud" pattern and the "Using Gateway" pattern.

If the machine sending the data has limited resources, you may want to use the simplest protocol possible.

MQTT is simpler than HTTP, but when encrypted communication is required, it is difficult to say which is more effective.

Mission-critical

In the case of MQTT, you might consider increasing the QoS.

MQTT's delivery guarantee is only between the publisher and the broker, so if you want to further guarantee that the data has been processed correctly in the backend, you may want to consider the AMQP protocol as an option.

Additionally, MQTT does not guarantee order. To perform processing that takes into account transactions and order guarantees, it is necessary to consider a commonly used message queue system rather than a protocol specialized for IoT.

Real-time

Achieving real-time performance means frequent data transfers, so MQTT is effective in reducing communication overhead.

If you want to always transfer the latest data even if there is some data loss, you may want to consider using UDP.

Device Control

If you want to give some instructions to a device, especially an IoT gateway, you can use a protocol that allows two-way communication or a message queue to periodically retrieve instructions from the device.

WebSocket is a protocol that enables two-way communication.

WebSocket uses a persistent connection with the server, which requires more resources from the server, whereas MQTT allows devices to act as subscribers, making it useful for device control.

summary

When considering building an IoT system, there are a wide variety of communication protocols and methods to compare and consider.

MQTT tends to attract a lot of attention in the context of IoT, but it is not being adopted because it is the best protocol; rather, it is being adopted as a result of various trade-offs.

When actually selecting a protocol or communication method, I think it is important not only to understand the characteristics of the protocol from various aspects, but also to consider how to cover the protocol's shortcomings.

Next time, we will focus on file transfer, a data transfer method, and consider safer and more reliable data transfer methods.

Introduction to IoT Architecture Column List

Related Content