Shulou(Shulou.com)06/03 Report--

Background

Communication protocol refers to the rules and agreements that both entities must follow to complete communication or service. Data communication systems in different geographical locations interconnected by communication channels and devices must have a common language in order to work together to achieve information exchange and resource sharing. What to communicate, how to communicate and when to communicate must follow certain rules that are mutually acceptable. This rule is the communication protocol.

In the Internet of things scenario, communication mainly occurs between devices and Internet of things platform. Because most of the Internet of things devices are resource-constrained devices, their physical resources and network resources are very limited, so it is too high for them to communicate directly using the existing HTTP protocol. Therefore, the communication protocols mainly used in the Internet of things scenarios are lightweight, designed for resource-constrained environments, such as CoAP/LWM2M protocol and MQTT protocol.

This article will explain the CoAP/LWM2M protocol and MQTT protocol for you respectively, hoping to help you understand these protocols and choose the communication protocol that works best for your device.

-CoAP/LWM2M protocol-

CoAP (Constrained Application Protocol, restricted application protocol) runs on the UDP protocol. Its design mainly draws lessons from the RESTful style of the HTTP protocol and simplifies the protocol packet format. The smallest CoAP packet is only 4 bytes. The CoAP protocol uses the same request / response model as the HTTP protocol. After the client sends the request, the server processes the request and replies to the response, which is a peer-to-peer communication model. CoAP, like HTTP, specifies the resources to be accessed through URI, but the CoAP protocol begins with "coap:\" or "coaps:\", where the s of coaps means that the message is encrypted through the DTLS protocol. Each message in CoAP is a binary message, which consists of the following parts:

VER: length 2 digits, used to represent the version number of the CoAP protocol.

T: 2 digits in length, used to indicate the type of message. The CoAP protocol defines four message types:

CON: a message that needs to be answered. After receiving the message, the receiver needs to reply an ACK message in time.

NON: a message that does not need to answer.

ACK: reply message.

RST: reset the message, when the recipient is unable to parse the received message or contains errors in the received message, it can reply to the RST message.

TKL: length of 4 digits, used to represent the length of the Token field.

Code: 8 bits in length, used to represent the request method (GET/POST/PUT/DELETE) in the request message and the response code (similar to the response code of HTTP) in the response message.

Message ID: 16 bits in length, used to identify messages. There are two main uses: one is that after receiving the CON message, the server needs to return the ACK message of the same Message ID; the other is to use the same Message ID to indicate that the same message is sent repeatedly.

Token: an optional field whose length is determined by TKL and is also used to identify messages. For example, sometimes when the server receives the CON message (with Token), the request cannot be processed immediately, so it can only reply to an ACK message without response data, and then bring the actual response data to the client through a CON or NON message after the request processing is completed. In this case, the message must carry the same Token as the previous CON message, telling the client that the message is the response of the previous CON message.

Similarly, if the client sends a NON message for the request, the server can also use the NON message to respond, and the two messages are associated with Token. In addition, Token can also be used in scenarios such as message anti-forgery, which is not described here.

Options: an optional field of varying length that acts like a header in the HTTP protocol.

1 1 1: separator used to separate Options and Payload.

Payload: the actual payload data, the message body in the HTTP protocol, is used to carry the actual content of this message, which can be empty.

If you want to know more about the CoAP agreement, you can visit the IETF website to view the details of the agreement.

Click to view the CoAP protocol specification

After learning about the CoAP protocol, let's take a look at the LWM2M protocol.

LWM2M (Lightweight Machine-To-Machine, lightweight M2M) protocol is a communication protocol of the Internet of things based on CoAP protocol proposed and defined by OMA (Open Mobile Alliance). LWM2M defines interfaces, objects and other specifications on the basis of CoAP protocol, which makes the communication between Internet of things devices and Internet of things platform more concise and standardized.

The LWM2M protocol defines three logical entities: LWM2M Server (server), LWM2M Client (client), and LWM2M Bootstrap Server (boot service), in which LWM2M Server and LWM2M Bootstrap Server can be the same server. Between these entities, the LWM2M protocol defines four interfaces:

Bootstrap: boot interface. After the client starts for the first time, the boot service can be accessed through this interface (the manufacturer is required to write the address of the boot server to the device in advance) and obtain the address of the server.

Device Discovery and Registration: device discovery and registration interface. Through this interface, the client writes its basic information to the server, including what capabilities it supports. This interface can also be used to upgrade registration information and log out of devices.

Device Management and Service Enablement: device management and service implementation interface. The server sends instructions to the client through the interface, and the client processes the instructions and returns the response. The interface defines seven operations, namely: "Create", "Read", "Write", "Delete", "Execute", "Write Attributes" and "Discover".

Information Reporting: information reporting interface. LWM2M allows the server to subscribe to the resource information from the client. After being subscribed, the client actively reports the information to the server according to the mode agreed by the interface (event trigger or periodically).

In the above interfaces, the server needs to specify a specific operation target when operating on the client, such as reading an attribute and writing an attribute. In the HTTP protocol, this target is specified through the URI or the text message carried in the message body. In order to make the communication message more concise, the LWM2M protocol defines the concept of object and resource.

An object is a collection of resources, and the LWM2M protocol defines eight standard objects, each of which is assigned an object ID of 07.For example, a firmware object with an object ID of 5. Considering the extensibility, the LWM2M protocol also allows users to customize new objects and assign object ID.

Each object must be instantiated before it can be used, because objects are abstract models, and an object can have multiple instances, each of which is a separate logical entity. When the object is instantiated, the instance ID is assigned, incremented from 0.

Resources can be understood as the attributes of objects and are the entities actually used to carry information in the LWM2M protocol. The carrying values of resources in different instances of the same object can be different. Each resource needs to be assigned a resource ID, for example, the firmware package name of the firmware object has a resource ID of 6. Like objects, the LWM2M protocol allows you to customize resources.

At this point, with object ID, instance ID, and resource ID, we can use three numbers to indicate a specific resource, such as the firmware package name that represents the first instance of the firmware object on 5-0-6. During the registration phase, the client writes examples of the objects it supports to the server to inform the server of its supported capabilities.

-MQTT protocol-

MQTT (Message Queuing Telemetry Transport, message queuing Telemetry Transport) protocol runs on top of TCP protocol and is a communication protocol based on publish / subscribe model. In the publish / subscribe model, we need a proxy server (often called Broker), and all clients need to establish a connection to the server and then subscribe and publish. If a client publishes a topic that other clients have subscribed to (called topic in the MQTT protocol), the server forwards the topic to all subscribed clients. For example, clients A, B, and C are all connected to the same server, B and C subscribe to the "test" topic, and then A publishes a message with the topic "test", and the server will forward the message to B and C.

In the Internet of things scenario, the Internet of things platform is both a server and a client. The platform formulates a set of topic rules (we can call it the MQTT interface) and subscribes to the topics of the data reporting interface, and then as long as the device uses this interface to report data, the platform can receive the data. Similarly, if a device wants to receive data from the platform, it needs to subscribe to the topic of the data distribution interface.

MQTT messages are transmitted based on text, and there are three main types of messages:

CONNECT: when the client wants to establish a connection with the server, it needs to send a CONNECT message to the server, which contains its own user name, password and other information. After the authentication of the server is passed, it establishes a connection with the client. If both parties want to disconnect, they need to follow the four-wave rule of the TCP protocol in order to disconnect normally. When sending a CONNECT message, the client can also specify a "last will" message, including the subject and content of the message. When the server detects an abnormal disconnection from the client, it automatically publishes this "last wish" message.

SUBSCRIBE: when the client subscribes to a topic, it needs to send a SUBSCRIBE message to the server to specify the topic to subscribe to. The topic of the MQTT protocol is represented as a hierarchical structure, similar to the file system, such as the format "/ huawei/v1/devices". Similarly, the client can unsubscribe to the specified topic through UNSUBSCRIBE messages.

PUBLISH: when the client publishes a message, it needs to send a PUBLISH message to the server, specifying the subject and content of the message. MQTT has no restrictions on the content format of published messages, and it is up to each service provider to make its own specifications. When the client publishes the message, you can specify whether the message needs to be retained. Only one message can be retained in a topic, and the retained message will be recorded by the proxy server. In the future, every client who subscribes to this topic will receive the reserved message first.

In terms of reliable transmission, the MQTT protocol provides three QoS-level implementations:

QoS=0 indicates that the message will only be sent once, but the message may be lost.

QoS=1 says to make sure the message arrives at least once, but it may cause subscribers to receive multiple duplicate messages.

QoS=2 means to make sure that the message arrives and only once.

The higher the QoS level, the higher the reliability of message transmission, but the more complex the implementation will be, and the more network and device resources will be occupied, so which level of QoS to choose for transmission needs to be chosen according to the actual situation.

-Summary-

After understanding CoAP/LWM2M protocol and MQTT protocol respectively, we can know that LWM2M protocol is a specific specification based on CoAP protocol, while MQTT protocol is another transport protocol different from CoAP protocol.

The CoAP/LWM2M protocol is based on the UDP protocol, and the connection between the server and the client is not maintained; the communication is based on the request / response model, which is the same as the mainstream HTTP protocol on the Internet, and is mainly used for point-to-point communication. The CoAP/LWM2M protocol defines various types and labels for the Internet of things scenario, supports content negotiation and discovery, and allows devices to detect each other to find a way to exchange data; the message is a minimalist binary message with shorter length and lower requirements for devices and networks.

The MQTT protocol is based on the TCP protocol, and the connection between the server and the client is maintained; the communication is based on the distribution / subscription model, which can easily realize the many-to-many communication scenario. MQTT protocol design is simple, easy to understand and learn; message message is based on text, message payload format is unlimited, higher degree of freedom, easier to view and understand when debugging and troubleshooting, but at the same time, it also requires service providers to develop communication specifications (interface documents), so that devices can communicate effectively.

To sum up, CoAP/LWM2M protocol and MQTT protocol have their own characteristics, and there is no one who is superior or inferior. You need to choose the most suitable protocol according to the application scenario of your device.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.