How to choose communication protocol for IoT terminal devices

At present, most IoT modules on the market support TCP, UDP, CoAP, LwM2M, MQTT and other protocols, including both transport layer protocols and application layer protocols. There are many protocols and different applicable scenarios. However, when designing a product, usually only one protocol is needed, so it is particularly important to choose a protocol that meets the application scenario of your product. This article will introduce the characteristics and differences of the five commonly used protocols TCP, UDP, CoAP, LwM2M, and MQTT, to provide a reference for the selection of protocols when designing products.

[[315675]]

1. Transport layer protocols TCP and UDP

TCP (Transmission Control Protocol) and UDP (User Data Protocol) are both transport layer protocols, providing the same level of communication reliability for upper-layer users.

1. Transmission Control Protocol (TCP):

TCP (Transmission Control Protocol) defines the format of data and confirmation information exchanged for reliable transmission between two computers, as well as the measures taken by the computers to ensure the correct arrival of data. The protocol specifies how TCP software can identify multiple destination processes on a given computer and how to recover from errors such as packet duplication. The protocol also specifies how two computers can initiate a TCP data stream transmission and how to end the transmission. The biggest feature of TCP is that it provides a connection-oriented, reliable byte stream service.

2. User Datagram Protocol (UDP):

UDP (User Datagram Protocol) is a simple datagram-oriented transport layer protocol. It provides non-connection-oriented, unreliable data stream transmission. UDP does not provide reliability, nor does it provide functions such as message arrival confirmation, sorting, and flow control. It only sends out the datagrams passed by the application to the IP layer, but it cannot guarantee that they can reach the destination. Therefore, the messages may be lost, duplicated, and out of order. However, since UDP does not need to establish a connection between the client and the server before transmitting the datagram, and there is no timeout retransmission mechanism, the transmission speed is very fast.

3. Differences between TCP and UDP

• TCP is connection-oriented (such as dialing to establish a connection before making a phone call); UDP is connectionless, that is, no connection needs to be established before sending data.
• TCP provides reliable service. That is, the data transmitted through the TCP connection is error-free, not lost, not duplicated, and arrives in order; UDP makes the best effort to deliver, that is, it does not guarantee reliable delivery.
• TCP is byte stream oriented, in fact, TCP regards data as a series of unstructured byte streams; UDP is message oriented. UDP has no congestion control, so network congestion will not reduce the sending rate of the source host (very useful for real-time applications, such as IP telephony, real-time video conferencing, etc.)
• Each TCP connection can only be point-to-point; UDP supports one-to-one, one-to-many, many-to-one and many-to-many interactive communications.
• TCP header overhead is 20 bytes; UDP header overhead is small, only 8 bytes 6. TCP's logical communication channel is a full-duplex reliable channel, while UDP is an unreliable channel

Second, is the transport layer protocol suitable for direct application to IoT device terminals?

The transport layer, as the name implies, is only responsible for transmitting data, just like a truck that transports goods. However, if you want the goods to be transported to the destination intact, you need to pack, load, inspect, store, sign the receipt, etc. This requires more work, which is what the application layer protocol needs to do. Therefore, if the IoT device terminal wants to interact with data stably and reliably, it needs to use the application layer protocol instead of the transport layer protocol directly. The following will introduce MQTT, CoAP, and LwM2M, three application layer protocols suitable for use on IoT device terminals.

3. Application layer protocols MQTT and CoAP

1. MQTT Overview

MQTT (Message Queuing Telemetry Transport) is an instant messaging protocol developed by IBM, which is likely to become an important part of the Internet of Things. The protocol supports all platforms and can connect almost all networked objects to the outside world. It is used as a communication protocol for sensors and actuators (such as connecting houses to the Internet through Twitter).

2. MQTT protocol features

The MQTT protocol is designed for communication between a large number of remote sensors and control devices with limited computing power and working on low-bandwidth, unreliable networks. It has the following main features:

• Use the publish/subscribe messaging model to provide one-to-many message publishing and decouple applications;
• Message transmission with shielding of payload content;
• Use TCP/IP to provide network connectivity;
• There are three message publishing qualities of service:

"At most once", message publishing is completely dependent on the underlying TCP/IP network. Message loss or duplication may occur. This level can be used in the following situations, such as environmental sensor data, where it does not matter if a read record is lost because a second send will be sent soon. "At least once", ensure that the message arrives, but message duplication may occur. "Exactly once", ensure that the message arrives once. This level can be used in the following situations, such as in the billing system, where message duplication or loss may lead to incorrect results. Small transmission, small overhead (fixed-length header is 2 bytes), and minimized protocol exchanges to reduce network traffic.

3. CoAP Overview

Since many devices in the Internet of Things are resource-constrained, that is, they have only a small amount of memory space and limited computing power, the traditional HTTP protocol is too large and inapplicable to the Internet of Things. The CoRE working group of IETF proposed a CoAP protocol based on the REST architecture. CoAP works in the UDP protocol family and uses a binary format. Compared with the text format used by HTTP, CoAP is more compact than HTTP.

4. CoAP protocol characteristics

• Message model, using messages as data communication carriers, and realizing data communication between devices by exchanging network messages
• All operations on cloud device resources are completed through a request and response mechanism, similar to HTTP. The device side can operate server-side resources through four request methods (GET, PUT, POST, DELETE).
• The protocol packet is lightweight, with a minimum length of only 4B.
• Supports reliable transmission, data retransmission, and block transmission to ensure reliable data arrival.
• Supports IP multicast, which means that requests can be sent to multiple devices at the same time
• Non-long connection communication, suitable for low-power IoT scenarios

5. Differences between MQTT and CoAP

4. So which one is more suitable for IoT devices, MQTT or CoAP?

In fact, both MQTT and CoAP are more suitable for IoT devices, but the choice of use still depends on the actual scenario. For example, if the device is running in a scenario where power consumption does not need to be considered but real-time control is required, such as charging piles, express cabinets, etc., it is more appropriate to use the MQTT protocol. If the device usually only reports data and is very sensitive to power consumption, such as water meters, gas meters, etc., it is more appropriate to use the CoAP protocol.

[[315677]]

With the rise of the Internet of Things, the era of the Internet of Everything will eventually arrive. However, due to cost and performance considerations, the resources of devices are often limited, so a protocol designed specifically for resource-constrained IoT devices is needed to meet the needs of the Internet of Everything, which is the LwM2M protocol.

1. LwM2M Overview:

OMA is an international organization that initially defined a set of OMA-DM protocols for remote management of mobile terminal devices, such as mobile phone account opening, version upgrades, etc. OMA-DM has a very wide range of applications. Many operators, such as Verizon Wireless and Sprint, have their own OMA-DM services and require mobile phones/modules to pass a customized OMA-DM network access test when they join the network. Due to the rise of the Internet of Things, OMA proposed the LwM2M protocol based on the traditional OMA-DM protocol. At the end of 2013, OMA released the LwM2M specification.

The main motivation of OMA Lightweight M2M is to define a set of lightweight protocols suitable for various IoT devices, because M2M devices are usually embedded terminals with very limited resources, no UI, limited computing power and network communication capabilities. At the same time, due to the huge number of IoT terminals, saving network resources becomes very important.

2. LwM2M protocol logical entity and logical interface

LwM2M defines three logical entities:

• LwM2M Server
• LwM2M client is responsible for executing server commands and reporting execution results
• LwM2M Bootstrap server is responsible for configuring LwM2M client.

There are 4 logical interfaces between these three logical entities:

• Device Discovery and Registration: This interface allows the client to register with the server and inform the server of the capabilities supported by the client (in simple terms, which resources and objects are supported).
• Bootstrap: Bootstrap server: Use this interface to configure the client - for example, the URL address of the LwM2M server Device Management and Service Enablement: This is the main business interface. The LwM2M Server sends instructions to the Client and receives a response.
• Information Reporting: This interface is used by LwM2M Client to report its resource information, such as sensor temperature. The reporting method can be event-triggered or periodic.

The relationship between these three logical entities and the four logical interfaces is as follows:

3. LwM2M protocol stack

The LwM2M protocol stack structure is shown in the figure below:

LwM2M Objects: Each object corresponds to a specific functional entity of the client. The LwM2M specification defines the following standard Objects, such as

 urn:oma:lwm2m:oma:2; (LwM2M Server Object)  
 urn:oma:lwm2m:oma:3; (LwM2M Access Control Object)

Each object can have many resources. For example, a Firmware object can have resources such as Firmware version number, size, etc.

Vendor can define its own object:

• LwM2M Protocol: defines some logical operations, such as Read, Write, Execute, Create or Delete.
• CoAP: It is a Constrained Application Protocol defined by IETF and is used as the transport layer of LwM2M. The lower layer can be UDP or SMS. UDP must be supported, and SMS is optional. CoAP has its own message header, retransmission mechanism, etc.

DTLS: is used to ensure security between the client and the server.

4. Relationship between LwM2M and CoAP

LwM2M messages do not have symmetrical feedback messages. Since LwM2M is carried on the CoAP protocol, using CoAP's get, post, put, and delete methods, the feedback on the success or failure of the corresponding message is achieved through the interaction of the CoAP protocol itself. LwM2M payloads support four formats: plain text, Opaque, TLV, and JSON. These four protocols require the server to support them all, and the client must support the TLV format.