Q: I am currently selecting a suitable cellular modem. The idea is that we will run sensor applications on a specific (STM32L4… ) MCU, which will communicate with either a cellular modem or LoRaWAN modem via an AT serial interface (not simultaneously). This is a departure from the single MCU application + LoRaWAN stack that we use now.
Part of the design is of course identifying an application-level protocol. There is one discussion on your site where you recommend CoAP for NB-IoT. We will be starting with LTE-M, using NB-IoT a bit later. Rather than CoAP (which I’ve used before) there is another choice now MQTT-SN over UDP, which is being promoted extensively by one manufacturer at least. As a fan of MQTT anyway, going the MQTT-SN route looks like a really good fit.
So I was interested if you had any thoughts on using that over CoAP?
IoT protocol comparison
The main difference between MQTT-SN and CoAp is that the former requires a broker. This means that its client nodes have less complexity, however the need for a broker could make a system more complex to integrate into an existing infrastructure. Overall energy requirements are similar as both work over UDP (see: Performance Evaluation of CoAP and MQTT_SN in an IoT Environment Mónica MartÃ, Carlos Garcia-Rubio and Celeste Campo. 13th International Conference on Ubiquitous Computing and Ambient Intelligence UCAmI 2019, Toledo, Spain, 2–5 December 2019)
The above graphic shows the number of bytes required to transmit a message. The red area shows the necessary protocol overhead of the carrier: TCP/IP or UDP/IP. TCP/IP specifies that the telegram must be acknowledged automatically after transmission. If the transmission is negative or there is no acknowledgement, TCP/IP repeats the message several times automatically. However, if the acknowledgement is impossible for technical reasons, TCP/IP burns energy and bandwidth unnecessarily.
NB-IoT is quite a new radio technology, however, data was transmitted via radio before NB-IoT. A praiseworthy example is 802.15.4 with 6LoWPAN. 6LoWPAN is a transmission protocol on IP (PPP) and was specified for radio and wired communications by small low powered devices. The layer above it is UDP (not TCP). If a radio channel is disturbed, then it generally makes no sense to start a new transmission of the telegram. UDP does not send an acknowledgement and does not expect an acknowledgement. If you elect to use UDP, then the acknowledgement must be done in the protocol layer above it. The protocol layer above UDP is usually CoAP in the case of 6LoWPAN, CoAP requires that a telegram is sent (with or without acknowledgement). This means that the programmer himself can decide whether he needs an acknowledgement or not. We serve a customer who has been using GPRS for over ten years and transmits his position data with a proprietary protocol based on UDP. 98% of his sent messages reach the server. Since the customer transmits every five seconds, the loss of a single message is unimportant. If you transfer this thinking to your design and use CoAP, then you can confidently do without the receipt, because 98% of the sent messages will arrive on the server. LWM2M is a protocol from the Open Mobile Alliance and is a layer above CoAP.
The structure as a glance
PPP => UDP/IP => CoAP => LWM2M
PPP => UDP/IP => MQTT-SN => not defined
PPP => TCP/IP => MQTT => not defined
In the akorIoT Group, we decided to use CoAP and defined the protocol layer above it ourselves. In addition, we have chosen an encryption method that is extremely secure and thus avoids the risk that third parties can read our data traffic. The encryption is from end-to-end and therefore neither the NB-IoT network operator nor other bad guys can read our communications.
The most convenient way with the highest energy waste is HTTPS with the JASON open standard file format. The most inconvenient way with the lowest energy consumption is NB-IoT NON-IP with its own protocol. It is also the way with the most barriers because NON-IP is not supported by all network operators. If you plan a local product for example only for Germany then you can use NON-IP without problems. If you plan like the akorIoT GROUP does Internationally, then NB-IoT with CoAP is a good approach. Whether you then use LWM2M as an application layer above or your own protocol layer, is up to you. LWM2M is a convenient approach, because not only the profiles of the telegrams are regulated there, but also the login to the server and the device management. LWM2M can also be used with SMS or based on LoRaWAN. The latest version of LWM2M is supporting TCP/IP as well.
The net is that CoAP does not expect an acknowledgement, or CoAP accepts an acknowledgement with extremely long elapsed time. By contrast, long acknowledgement coupled with TCP/IP and its compulsion for receipts resulting in multiple resends will be the death of your battery.
I hope, I could bring a little light into the darkness with my graphics. Unfortunately many people still confuse the bearer and the protocol layers above the bearer. I, therefore, recommend that you take a quick look at the OSI layer model even if the TCP/IP or UDP protocol does not follow the layer model exactly.
1. Is it worth mentioning about the QoS concept in this blog. Normal MQTT over TCP uses QoS which can ensure data packets are not lost, but using levels like QoS=2 will cause a significant increase in overhead and additional time delay
2. Are QoS levels considered in the UDP use cases, and will it improve the efficiency
3. For critical tracking applications, loss of data may still be a concern. Any suggestions of protocol for these applications
CoAP (Constrained Application Protocol) operating over UDP offers flexible communication options, with or without acknowledgment, catering to various IoT application needs. This versatility makes it an excellent choice for resource-constrained devices and networks.
Unacknowledged CoAP Messages
For applications like GNSS trackers that continuously transmit location data, unacknowledged CoAP messages are often sufficient[1]. These devices send frequent position updates, making the loss of an occasional packet less critical. The same principle applies to water meters, which regularly report consumption data[5]. In these scenarios, the consistent stream of data compensates for potential packet loss, ensuring overall system reliability without the overhead of acknowledgments.
Acknowledged CoAP Messages
When message delivery confirmation is crucial, CoAP provides an option for acknowledged communication[1][4]. This mode ensures that the server receives and processes each message, offering a higher level of reliability. It’s particularly useful for critical applications where data loss could have significant consequences.
Efficiency and Network Performance
CoAP’s design significantly reduces the number of packets required for payload transmission compared to other protocols[3]. This efficiency translates to:
1. Reduced network traffic: Fewer packets mean less congestion on the network.
2. Improved connection quality: Especially beneficial in low-signal-strength environments.
3. Better performance with high packet loss: The protocol’s efficiency helps maintain functionality even when network conditions are poor.
Technical Advantages
– UDP-based: CoAP leverages UDP’s lightweight nature, making it ideal for constrained devices.
– Flexible message types: Supports both Confirmable (CON) and Non-confirmable (NON) messages.
– Compact header: The base header is just 4 bytes, minimizing overhead.
– Optional reliability: Offers a message confirmation mechanism when needed.
Application-Specific Considerations
When choosing between acknowledged and unacknowledged CoAP messages, consider:
– Data criticality: How important is each individual data point?
– Transmission frequency: Higher frequency can often compensate for occasional losses.
– Network conditions: In highly unreliable networks, acknowledged messages may be preferable.
– Device power constraints: Unacknowledged messages can help conserve energy.
By carefully selecting the appropriate CoAP mode, developers can optimize their IoT solutions for efficiency, reliability, and performance, even in challenging network environments.