Introduction to IoT Communication Protocol
For convenience, IoT communication protocols are divided into two categories: access protocols and communication protocols. Access protocols are generally responsible for networking and communication between devices in a subnet; communication protocols are mainly device communication protocols running on the traditional Internet TCP/IP protocol, responsible for data exchange and communication between devices through the Internet. This article mainly introduces communication protocols.
Let’s talk about the access protocol first
Common protocols on the market include zigbee, Bluetooth, and wifi.
1. Zigbee
Zigbee is currently widely used in the field of industrial control and also has certain applications in the field of smart homes. It has the following main advantages:
1. Low cost. The Zigbee protocol has a low data transmission rate and a simple protocol, so the development cost is relatively low. In addition, the Zigbee protocol is free of patent fees.
2. Low power consumption. Due to the low transmission rate of the Zigbee protocol, the node requires only 1mW of transmission power, and uses a sleep + wake-up mode, which consumes very little power.
3. Self-organizing network. Through the mesh function of the ZigBee protocol, up to 65,000 nodes can be connected in a sub-network, which can quickly realize a large-scale sensor network.
4. Security. Use CRC to verify the integrity of data packets, support authentication and authorization, and use AES-128 to encrypt transmission data.
The best application scenario for the Zigbee protocol is wireless sensor networks, such as water quality monitoring, environmental control, and other industrial scenarios where nodes need to self-organize to transmit data. In these scenarios, the advantages of the Zigbee protocol are very obvious.
Why do manufacturers abandon the more widely used WiFi and Bluetooth protocols and adopt Zigbee? The main reasons are as follows:
1. As mentioned earlier, the ZigBee protocol has strong self-organizing networking capabilities and can support tens of thousands of devices. Especially for companies like Xiaomi that want to build a smart home ecosystem, the number of device connections for WiFi and Bluetooth is currently a major limitation.
2. Currently, the Zigbee protocol is still difficult to crack, while other protocols have always been criticized for their security.
3. Many smart home products, such as door sensors, generally use built-in batteries for ease of use. At this time, Zigbee's ultra-low power consumption greatly improves the product experience.
However, the Zigbee protocol also has its shortcomings. The main one is that although it can be easily networked, it cannot access the Internet. Therefore, there must be a node in the Zigbee network that acts as a router (such as the smart gateway in the Xiaomi smart home kit), which increases the cost and the user's threshold for use. At the same time, due to the low data transmission rate of the Zigbee protocol, it is basically impossible for large-traffic applications such as streaming media and video.
Compared with the rapid development and commercial popularization of WiFi and Bluetooth protocols in recent years, the Zigbee protocol has great advantages in technical design and architecture, but its technology updates are too slow and it has been left behind by competitors in market promotion. There is still a lot of room for the Zigbee protocol in the industry, but it is not so easy to challenge WiFi and Bluetooth protocols in the home and consumer fields.
2. Bluetooth
Bluetooth has now become a standard communication component for smartphones. The reasons for its rapid development include:
1. Low power consumption. I think this is the killer feature of Bluetooth 4.0. Bluetooth 4.0 devices using button batteries can run for more than a year, which is very attractive for wearable devices that do not want to be charged frequently.
2. Popularity of smart phones. In recent years, support for Bluetooth protocol has basically become a standard feature of smart phones, and users do not need to purchase additional access modules.
3. Wi-Fi
Like the Bluetooth protocol, the WiFi protocol has also been greatly developed. Due to the rapid popularization of home WiFi routers and smart phones in the past few years, the WiFi protocol has also been widely used in the field of smart homes. The biggest advantage of the WiFi protocol is that it can directly access the Internet. Compared with Zigbee, the smart home solution using the WiFi protocol eliminates the need for additional gateways, and compared with the Bluetooth protocol, it eliminates the need for mobile terminals such as mobile phones.
Equivalent to Bluetooth and Zigbee, the power consumption of the WiFi protocol has become a major bottleneck in its application in the field of the Internet of Things. However, as major chip manufacturers have successively launched low-power, low-cost WiFi SoCs (such as ESP8266), this problem is gradually being solved.
Who will unify the world?
Which one will dominate the IoT field, the Wi-Fi protocol or the Bluetooth protocol? This is a topic that is currently being discussed a lot. The technical advantages of Wi-Fi and Bluetooth can be mutually improved in the process of protocol upgrades. Currently, both protocols are developing in the direction of "taking advantage of each other's strengths". Who will eventually dominate may be determined more by commercial forces and the market. In the short term, each protocol is definitely applicable to different scenarios and has its own value.
Let's talk about communication protocol
For the Internet of Things, the most important thing is the communication between devices on the Internet. Now the more common communication protocols in the Internet of Things include: HTTP, websocket, XMPP, COAP, MQTT
1、HTTP和websocket
In the Internet era, TCP/IP protocol has dominated the market, and the current communication architecture of the Internet of Things is also built on the traditional Internet infrastructure. Among the current Internet communication protocols, HTTP protocol occupies almost half of the market due to its low development cost and high degree of openness, so many manufacturers also develop based on HTTP protocol when building Internet of Things systems. Including the Physic Web project led by Google, they all hope to build the Internet of Things protocol standard based on traditional web technology.
The HTTP protocol is a typical CS communication mode, where the client actively initiates a connection and requests XML or JSON data from the server. The protocol was originally designed for web browsers and is currently widely used on PCs, mobile phones, pads and other terminals, but is not suitable for IoT scenarios. It has three major drawbacks in IoT scenarios:
1. Since the device must actively send data to the server, it is difficult to actively push data to the device. It is barely applicable for simple data collection scenarios, but for frequent control scenarios, it can only be pushed by the device to actively pull data regularly, which greatly reduces the cost and real-time performance.
2. Low security. The insecurity of the web is well known to everyone. HTTP is a plain text protocol. In many IoT scenarios that require high security, if a lot of security preparations are not done (such as using https, etc.), the consequences will be disastrous...
3. Different from user interaction terminals such as PCs and mobile phones, the devices in IoT scenarios are diverse. For devices with very limited computing and storage resources, HTTP protocol implementation and XML/JSON data format parsing are "mission impossible".
Therefore, when designing the IoT cloud platform, the Panduo IoT team only used the HTTP protocol for mobile phone or PC users, and did not use the HTTP protocol for IoT access of devices.
Of course, there are still many manufacturers who choose to build IoT systems based on the HTTP protocol for the sake of development convenience. If device resources permit, how to avoid the problem of low real-time data push mentioned above?
Websocket is a feasible solution. Websocket is a protocol standard proposed by HTML5 that supports full-duplex communication based on TCP. Its design basically follows the idea of HTTP and is a good supplement to the Internet of Things system based on HTTP protocol.
2、XMPP
Since the communication mode of IoT devices is very similar to the instant messaging applications on the Internet, the instant messaging protocols commonly used on the Internet are also widely used in the construction of IoT systems, a typical example of which is XMPP.
XMPP is an XML-based protocol. Due to its openness and ease of use, it is widely used in Internet instant messaging applications. Compared with HTTP, XMPP is more suitable for IoT systems in terms of business processes of communication. Developers do not need to spend too much time to solve the business communication process when devices communicate, and the development cost is relatively lower. However, the security and computing resource consumption flaws in the HTTP protocol have not been fundamentally solved. The TCL washing machine that was easily cracked by hackers some time ago used the XMPP protocol.
Whether it is HTTP, websocket or XMPP, they are all designed based on Internet application scenarios. Although many manufacturers apply them in IoT systems, they are bound to be unsuitable. The common problem of these protocols is that they are simply unable to adapt to the diversity of IoT devices and the low power consumption and low cost requirements of many IoT devices. They are difficult to use in IoT devices with extremely low resources. Is there a protocol that can borrow the design ideas of web technology while adapting to the harsh operating environment of IoT devices?
The COAP protocol came into being.
3、COAP
The design goal of the CoAP protocol is to realize IoT communication on low-power and low-speed devices. CoAP, like the HTTP protocol, uses URLs to indicate the data to be sent. The design of the protocol format is also basically based on the HTTP protocol, which is very easy to understand. At the same time, the following optimizations have been made:
1. Use UDP instead of TCP. This saves the cost of establishing a TCP connection and the overhead of the protocol stack.
2. Use binary compression on data packet headers to reduce the amount of data to adapt to low network rate scenarios.
3. Sending and receiving data can be done asynchronously, which improves the device response speed.
The COAP protocol is like an HTTP transplant for IoT scenarios. Many designs retain the shadow of the HTTP protocol, and developers with a web background can quickly get started. However, since many IoT devices are hidden inside the local area network, the coap device as a server cannot be addressed by external devices. Before IPv6 is popularized, coap can only be used for communication within the local area network (such as WiFi), which greatly limits its development.
4. MQTT protocol
The MQTT protocol solves the problems of coap very well. The MQTT protocol is an instant messaging protocol developed by IBM, which is relatively suitable for the communication protocol of the Internet of Things scenario. The MQTT protocol adopts the publish/subscribe mode. All IoT terminals are connected to the cloud through TCP. The cloud manages the communication content of each device through the topic method and is responsible for forwarding messages between devices.
MQTT takes into account the differences in computing performance of different devices when designing the protocol, so all protocols are encoded and decoded in binary format, and the encoding and decoding formats are very easy to develop and implement. The smallest data packet is only 2 bytes, and it is also very adaptable to low-power and low-speed networks. There is a very complete QOS mechanism, and three message delivery modes can be selected according to the business scenario: at most once, at least once, and exactly once. It runs on the TCP protocol and supports the TLS (TCP+SSL) protocol. Since all data communications pass through the cloud, security is well guaranteed.
The current IoT communication protocols are really diverse, and no protocol can dominate the market. However, to achieve the interconnection and interoperability of IoT devices (different manufacturers, different platforms, different architectures), the key point is not the unification of the above access protocols or communication protocols, but the unification of the upper-layer business application layer protocols. Whether it is wifi, Bluetooth, or mqtt, http, they are all channels for devices to communicate and exchange data, and what is specified is the format of communication; and the unification of the content of communication is the key to achieving interconnection and interoperability.
5、DDS
DDS (Data Distribution Service for Real-Time Systems) is a data distribution service for real-time systems. This is a protocol proposed by the famous OMG organization. Its authority should be able to prove the future application prospects of the protocol.
Scope of application: Distributed high reliability, real-time transmission equipment data communication. Currently, DDS has been widely used in defense, civil aviation, industrial control and other fields.
Features:
• Data-centric
• Use agentless publish/subscribe messaging mode, point-to-point, point-to-many, many-to-many
• Provide up to 21 QoS service quality strategies
The main implementations of the protocol are:
• OpenDDS is an open source C++ implementation
• OpenSplice DDS
Comments: DDS supports data distribution and device control between devices, as well as data transmission between devices and the cloud. At the same time, DDS has a very high real-time efficiency in data distribution, and can distribute millions of messages to many devices simultaneously within seconds. DDS provides a lot of ways to ensure quality of service (QoS), which is why it is suitable for high-reliability and security applications such as national defense, military, and industrial control. However, these applications all work in wired networks. In wireless networks, especially when resources are limited, there are no implementation cases.
Just scan and follow us~
If you feel good, please
Forward
Forward
Forward