How to Choose Access Protocols for IoT Devices

Currently, most IoT modules on the market support protocols such as TCP, UDP, CoAP, LwM2M, and MQTT. Among these, there are both transport layer protocols and application layer protocols, with many protocols available for different scenarios. However, when designing a product, usually only one protocol is needed, so how to choose a protocol that fits the application scenario of your product is particularly important. This article will introduce the characteristics and differences of five commonly used protocols: TCP, UDP, CoAP, LwM2M, and MQTT, providing a reference for protocol selection during product design.

Transport Layer Protocols: TCP and UDP

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

User Datagram Protocol (UDP): UDP (User Datagram Protocol) is a simple connectionless transport layer protocol. It provides unreliable data stream transmission that is not connection-oriented. UDP does not provide reliability, acknowledgment of message arrival, ordering, or flow control. It merely sends out datagrams passed from the application layer to the IP layer but cannot guarantee their arrival at the destination. Therefore, messages may be lost, duplicated, or out of order. However, since UDP does not need to establish a connection between the client and server before transmitting datagrams and does not have timeout retransmission mechanisms, its transmission speed is very fast.

Differences Between TCP and UDP

Difference	TCP	UDP
Connection-oriented	Connection-oriented	Connectionless
Transmission Reliability	Reliable	Unreliable
Application Scenarios	Small data volumes	Large data volumes
Speed	Slow	Fast

1. TCP is connection-oriented (like making a phone call requires dialing to establish a connection); UDP is connectionless, meaning no connection needs to be established before sending data.

2. TCP provides reliable service. That is, data transmitted through a TCP connection is error-free, not lost, not duplicated, and arrives in order; UDP does its best to deliver, which does not guarantee reliable delivery.

3. TCP is byte stream-oriented, essentially treating data as a series of unstructured byte streams; UDP is message-oriented.

UDP does not have congestion control, so network congestion does not reduce the sending rate of the source host (which is useful for real-time applications such as IP telephony and real-time video conferencing).

4. 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 communication.

5. TCP header overhead is 20 bytes; UDP header overhead is small, only 8 bytes. 6. TCP’s logical communication channel is a reliable full-duplex channel, while UDP is an unreliable channel.

Are Transport Layer Protocols Suitable for Direct Use in IoT Device Terminals?

As the name suggests, the transport layer is only responsible for data transmission, similar to a truck carrying goods. However, to ensure that the goods reach their destination intact, additional work such as packaging, loading, inspection, warehousing, and signing receipts is required, which is the work that application layer protocols need to perform.Therefore, for IoT device terminals to achieve stable and reliable data interaction, application layer protocols must be used, and transport layer protocols cannot be used directly.The following will introduce three application layer protocols suitable for use in IoT device terminals: MQTT, CoAP, and LwM2M.

Application Layer Protocols: MQTT and CoAP

1. Overview of MQTT

MQTT (Message Queuing Telemetry Transport) is an instant messaging protocol developed by IBM, which could become an important part of the IoT. This protocol supports all platforms and can connect almost all networked items with external connections, used as a communication protocol for sensors and actuators (e.g., connecting homes via Twitter).

2. Characteristics of the MQTT Protocol

The MQTT protocol is designed for communication between remote sensors and control devices with limited computing power, operating in low bandwidth and unreliable networks, and has the following main features:

1. Uses a publish/subscribe messaging pattern, providing one-to-many message publishing, decoupling applications;

2. Message transmission is masked by payload content;

3. Uses TCP/IP for network connectivity;

4. There are three levels of message publishing quality of service:

“At most once,” message delivery relies entirely on the underlying TCP/IP network. Message loss or duplication may occur. This level can be used for cases where environmental sensor data is sent, where losing one reading is inconsequential as a second one will be sent soon after. “At least once,” ensures message arrival, but duplication may occur. “Exactly once,” ensures the message arrives once. This level can be used in cases where message duplication or loss could lead to incorrect results in billing systems. Small transmission, low overhead (fixed-length header is 2 bytes), and minimal protocol exchange to reduce network traffic.

3. Overview of CoAP

Many devices in the IoT are resource-constrained, having only a small amount of memory and limited computing power, making traditional HTTP protocols too bulky and unsuitable for the IoT. The IETF’s CoRE working group proposed a REST architecture-based CoAP protocol. CoAP operates in the UDP protocol family and uses a binary format, which is more compact than the text format used by HTTP.

4. Characteristics of the CoAP Protocol

1. Message model, using messages as the data communication carrier, achieving data communication between devices through network message exchange;

2. Operations on cloud device resources are completed through a request-response mechanism, similar to HTTP, where the device side can operate on server-side resources using four request methods (GET, PUT, POST, DELETE).

3. The protocol packet is lightweight, with a minimum length of only 4B.

4. Supports reliable transmission, data retransmission, and block transmission, ensuring data reliably reaches its destination.

5. Supports IP multicast, meaning requests can be sent to multiple devices simultaneously.

6. Non-long connection communication, suitable for low-power IoT scenarios.

5. Differences Between MQTT and CoAP

Category	MQTT	CoAP
Communication Mechanism	Asynchronous	Synchronous
Connection Method	TCP	UDP
Communication Mode	Many-to-many	Many-to-one
Usage Scenarios	More suitable for push and IM	IoT
Power Consumption	High power consumption	Low power consumption
Reverse Control	Can be used for reverse control	Non-long connection, not suitable for reverse control

So which is more suitable for use in IoT devices: MQTT or CoAP?

Both MQTT and CoAP are quite suitable for IoT devices, but the choice should be based on the actual scenario. For example, in a scenario where devices operate without considering power consumption but require real-time control, such as charging piles or express cabinets, MQTT is more appropriate. If devices typically only report data and are sensitive to power consumption, such as water meters or gas meters, then CoAP is more suitable.

With the rise of the IoT, the era of interconnected everything is bound to come.However, considering cost and performance, devices are often resource-constrained, thus requiring a protocol specifically designed for resource-constrained IoT devices to meet the needs of interconnectivity, which is the LwM2M protocol.

1. Overview of LwM2M:

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 activation, version upgrades, etc. OMA-DM has a very wide range of applications, and many operators, such as Verizon Wireless and Sprint, have their own OMA-DM services and require mobile phones/modules to pass custom OMA-DM network testing when accessing the network. With the rise of the IoT, 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, as M2M devices are typically resource-limited embedded terminals with no UI and limited computing and network communication capabilities. Additionally, due to the vast number of IoT terminals, saving network resources becomes crucial.

2. Logical Entities and Interfaces of LwM2M Protocol

LwM2M defines three logical entities:

1. LwM2M Server

2. LwM2M Client responsible for executing commands from the server and reporting execution results.

3. LwM2M Bootstrap Server responsible for configuring LwM2M clients.

There are four logical interfaces among these three logical entities:

Device Discovery and Registration: This interface allows clients to register with the server and notify the server of the capabilities supported by the client (simply put, which resources and objects are supported).

Bootstrap: Bootstrap Server: This interface configures 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 responses.

Information Reporting: This interface allows LwM2M Clients to report their resource information, such as sensor temperature. Reporting can be event-triggered or periodic.

The relationship between these three logical entities and four logical interfaces is shown in the following diagram:

3. LwM2M Protocol Stack:

The structure of the LwM2M protocol stack is shown in the following diagram:

LwM2M Objects
LwM2M Protocol
CoAP
DTLS
UDP	SMS

LwM2M Objects: Each object corresponds to a specific functional entity of the client. The LwM2M specification defines several 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, the Firmware object can have resources such as the Firmware version number and size.

Vendors can define their own objects.

LwM2M Protocol: Defines some logical operations such as Read, Write, Execute, Create, or Delete.

CoAP: is the Constrained Application Protocol defined by IETF used for LwM2M transport, where the lower layer can be UDP or SMS. UDP is a must-support, while SMS is optional. CoAP has its own message headers, retransmission mechanisms, etc.

DTLS: is used to ensure security between clients and servers.

4. Relationship Between LwM2M and CoAP:

LwM2M messages do not have symmetric feedback messages. Since LwM2M is carried over the CoAP protocol, the feedback for successful or failed response messages is achieved through the interaction of the CoAP protocol itself using get, post, put, delete methods. The LwM2M payload supports four formats: plain text, opaque, TLV, JSON, and all four formats must be supported by the server side, while the client must support TLV format.

1

-END-

Previous Reviews

• Classes continue without interruption, together combating the epidemic, free learning of the full series of IoT tutorials

• The first overseas AIoT innovation training camp using the Little Bear IoT development kit launched in Singapore
• Finally, someone can explain the eDRX and PSM technology of NB-IoT thoroughly
• Little Bear, in collaboration with Huawei Cloud and ST, has released end-to-end IoT development tutorials (with benefits inside)
• The difference between Little Bear and Raspberry Pi, and its various models