With the extra space required for TCP headers/response what is the real world impact we can expect compared to using UDP for upload? In relation to power consumption.
Hi James
TCP protocol is completed by module encapsulation, and packet header and packet tail are also allocated space by the bottom of the module. For users, UDP/TCP packet header and packet tail are not considered.
TCP is a long connection, which leads to high power consumption.
In Germany, we say a picture says more than 1000 words. The English proverb is “A picture paints a thousand words.” The German and English proverb are therefore very similar. Many words have been used by others in the answers so far but no picture. So I will start my answer with a picture. The akorIoT Group has a reference design for a tracker with an open block diagram using the BG96. We are therefore very familiar with the possibilities of the Quectel BG96.
IoT protocols comparison
TCP, UDP, MQTT, MQTT-SN, CoAP, LWM2M, HTTP
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 unnecessarily. NB-IoT is quite a new radio technology. However, data was already 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 wire. 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 user 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 regulates 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 fithinking tothe 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 arrive on the server. LWM2M is based on CoAP. LWM2M is a protocol 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 for CoAP and defined the protocol layer above it ourselves. In addition, we have chosen an encryption method that is extremely secure and thus avoids that 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 JASON. The most inconvenient way with the lowest energy consumption is NB-IoT NON-IP on UDP 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 Internationally, then NB-IoT with CoAP is a good approach. Whether you then use LWM2M above, or your own protocol layer, is up to you. LWM2M is a convenient way, 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 background is that CoAP does not expect an acknowledgement or CoAP accepts an acknowledgement with an extremely long runtime. Long runtimes are normal with TCP/IP and its compulsive receipt will be the death of your battery.
I hope, I could bring a little light into the darkness with my show graphics. Unfortunately many 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.
akorIoT SensPRO working principle
Regardless of your earlier question, you can ask me for the reference design with an open block diagram and open addresses for all radio modules and sensors for less than €200 . I am co-founder of the akorIoT idea. I will then help her to make a custom copy of my own device or we will make the custom copy for you. The antenna in the reference design akorIoT SensPRO costs you zero Euro or zero Dollar. The antenna cannot be taken over so simply, because this antenna changes depending on the size of the board and the housing again and again. We therefore always adapt the antenna to the customer’s specific requirements. So if you want to make the copy of our reference design yourself, we will only take care of the copy of the antenna if necessary.
harald.naumann (at) lte-modem.com
2 Likes
Hi Harold, thankyou very much for your detailed and well written response. We currently use UDP on our device and since writing the original question have completed some of my own testing and have seen what you described with TCP; in the form of additional power usage even after the acknowledgement has been received, but uses way more power than UDP if the message is not received. I actually saw that same infographic on your LinkedIn and it explains the differences very well and it indeed does bring light into the darkness. Thanks again for your excellent response.