Out of LwM2M & MQTT, Which is the best suitable protocol for the assert tracking

[shiv_patil]

Hello Community,

I working on the Quectel BG-96 LPWA module. Our application is based on the assert tracking.
We need to send the current position of the device to a remote server after particular interval.

I am looking for the light weight protocol which consumes less power & headers added to the data packet.

As MQTT & LwM2M both are light weight & power saving protocol.
I am not able to make a decision, which protocol is more efficient for our product development.

Will you please help me to understand this concept.

[Abner-Q]

Hi Shiv_patil

It is recommended that you use UDP protocol, as MQTT protocol is a long connection rather than power saving protocol.

[Abner-Q]

Hi Shiv_patil

UDP protocol is unreliable, but can be avoided by retransmission mechanism.

MQTT protocol is a long connection with high power consumption, which cannot meet your requirements.

If power consumption is considered, it is still recommended to use LWM2M protocol to complete.

[shiv_patil]

What about the TCP/IP protocol?
Is it better than the MQTT?

I have also seen that LWM2M protocol is based on the MQTT protocol? Is it true?.
If Yes how it is going to save the power?

LwM2M over MQTT

MQTT Vs LwM2M

[Abner-Q]

Hi Shiv_patil

MQTT is based on TCP/IP, and MQTT is better than TCP/IP

LWM2M is UDP based and MQTT is TCP based.

MQTT has three handshakes and four waves, so the amount of data is relatively large.

LWM2M only transfers data and the amount of data is relatively small.Therefore, LWM2M is better than MQTT in power consumption.

We still recommend using LWM2M protocol on nb-iot.

[achimkraus]

Have a look at CoAP (over DTLS) (RFC7252/RFC6347).
This is also the protocol LWM2M is based on.
CoAP provides different message types, CON(firmed) messages uses ACK and retransmissions.
CoAP is very similar to HTTP offering REST. In advance, it’s very easy to have both coap-client and coap-server on one peer, that makes bidirectional communication working without additional conventions or specifications.
CoAP offers a “observe/notify” pattern (RFC7641). But be very careful with that! Especially if you power off/on your module you may get an other ip-address, which then doesn’t make it easy to use RFC7641. It’s also not intended for “loss free time series” even if a lot of people try to.
My recommendation would be, that you just use a PUT or POST request (device to server) and process this by convention. You may add also a resource to your device, which could be used form the server to configure the that sending mechanism.

If you want to use encryption, what would strongly recommend in a public internet, you may be faced the issue, that ip-address changes frequently changes the security association. With RFC6347 you will need frequently resume your session, what will add extra traffic and delay.
The IETF discuss a DTLS 1.2 extension “Connection ID”, which overcomes that. For close timelines, that may be too early.

[wwadepohl]

MQTT is an transport protocol only. There are no semantics nor coding rules for the messages. Everything you do ist proprietary and not standard. You can also use MQTT-SN for datagram (UDP) networks.

OMA lwM2M has also semantics standardized. Together with IPSO Smart Objects you will get a standard for your communication. Management is a important task if using cellular networks. lwM2M has also objects for management. Also the encoding is standardized.

IMHO lwM2M ist the better way to go. MQTT based solutions uses to much proprietary staff. that’s may be the reason why AWS and Azure focuses an MQTT to get the user “locked-in”.

You can secure it with DTLS. There are also some open-source implementations clinet and server, i. e. Anjay (C-Client), Eclipse Wakaama (C Client/Server), Eclipse Leshan (Java Client/server). For DTLS there are mbed TLS, tinydtls and others.

[shiv_patil]

Thanks Abner & Achimkraus,

From my point of view,
This both soultions are not suitable for our application development.
I will quickly gives you a introduction.

I am developing a tracking device whch is battery operated. Also in our case size of the device do matters.
So… I am looking for a lightweight protocol which will help me to save the battery even while transfering the data over network.
After transfering the data I wants swich off all the netweork communications & put the device in power saing mode. This will happens periodically.
Even I wants to be get ACK/NACK for each data sent to the server or any other receiveing node.

In LwM2M I will not able to get the ACK from the end device as it is based on the UDP protocol.
When ever I will diconnect the internet service form the module & rejoin it. I will alway get a new IP address. So CoAP also has some limitation to get it done.

How can I am able to save the battery by putting a lightweigth communication interface & module in PSM mode to drive the Module for atleast few days (atleast 2-3 Day’s with 1000mAH battery backup)

Will you please help me to solve this problem?

[achimkraus]

After transfering the data I wants swich off all the netweork communications & put the device in power saing mode. This will happens periodically.
Even I wants to be get ACK/NACK for each data sent to the server or any other receiveing node.

I’m not sure, if you want to express, that you can’t wait for a ACK. As far as I know, if you use a IP protocol, reliability without such a ACK is not possible. Either with TCP nor UDP. Usually, even with CAT-NB, the round trip should be something as 1-2s for a UDP message. With CAT-NB TCP it’s about 10s for the connection and after that 1-2s for the message round trip.

When ever I will diconnect the internet service form the module & rejoin it. I will alway get a new IP address. So CoAP also has some limitation to get it done.

CoAP itself (if you don’t stick to LWM2M) will not be affected from that. When the device is connected and a new ip-address is received, the device sends a POST-request with that address. It must stay for a few seconds on, until the ACK is received. If the request times out, the device must repeat it’s request, what is usually handled by the coap-library itself, if the CON message type is used. So the device must kept powered until the request/ACK has finished (mostly with a small piggybacked response as 2.04 changed/OK in the ACK).

With encryption, very recommended for mid-/long-term solution, DTLS 1.2 RFC6347 uses the ip-address to associate the encryption context. With that, for now, a “(resumption) handshake” is required. That add some more messages (some 100 bytes) and also some round trips (1 to 2) to your communication ending up in about 10s on(line).
As I mentioned in my first comment, DTLS 1.2 Connection ID, currently in discussion, would solve this without a new (resumption) handshake.

Let me end:
In my experience someone must be very familiar with the protocols to achieve a reliable, power economical solution. It’s not too easy.

[Darren_Olson]

Hi Shiv,
I would recommend what others have done in the past.
We have been using Digital Matter’s Battery powered Remora tracker for 4 years now.
The tracker transfers its data via TCP/HTTP POST in Json format.
The tracker has an onboard accelerometer to detect movement and when not moving puts the modem in low power mode.
The tracker is powered via Lithium Thionyl Chloride batteries that provide high amp/hr ratings.
We have the tracker deployed on trailers for more than a year without changing batteries.

Just some considerations, incorporate an accelerometer and high ampere batteries too.

[Darren_Olson]

For small space, take a look at Digital Matters Oyster tracking unit. It uses 3 AA batteries, has an onboard accelerometer and is quite small.
I like that the BG96 has an internal GPS and is certified on our networks in Canada.
The BG96 is certified on more networks worldwide than Ublox at the moment.

[cbrake]

+1 for CoAP – there is not much difference in doing acks/retries in the network stack (TCP/IP) or at the application level (UDP) – in the end it is really the same thing. With UDP based solutions (CoAP, LwM2M), you at least have more control over exactly what happens and typically requires less data to be transferred over the network.

[Harald_Naumann]

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 in the answers so far but no picture. So I start my answer with a picture. The akorIoT group has a reference design for a tracker with an open block diagram on the BG96. We are therefore very familiar with the possibilities of the Quectel BG 96.

The above graphic shows the number of bytes required to transmit a message. The red area shows the necessary protocol overhead of the used 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 a quite 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 decide for 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 five seconds, the loss of a message is unimportant. If you transfer this thinking to 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.
PPP => UDP/IP => CoAP => LWM2M
PPP => UDP/IP => MQTT-SN => not defined
PPP => TCP/IP => MQTT => n,ot 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 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 communication.

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 International, then NB-IoT with CoAP is a good way. Whether you then use LWM2M above or your own protocol layer is specified is up to you. LWM2M is again 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 extremely long runtime. Long runtimes are with TCP/IP and its compulsive receipt the death of your battery.

I hope, I could bring a little light into the darkness with my show graphics. Unfortunately many still mixed the bearer and the protocol layers above the bearer. I, therefore, recommend a quick look at the OSI layer model even if the TCP/IP or UDP protocol does not follow the layer model exactly.

Independently of that, 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 the 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 fit the antenna to the customer’s requirements. harald.naumann (at) lte-modem.com

[andras.szabo]

As power is most important, it should be the fastest connection and then shutdown. Overbloated protocols are not your friend, for example MQTT.

I think if a sometimes lost packet is not a problem, then send 3x UDP packets, hope for the best, then go to sleep. Otherwise a simple TCP/IP would be the best, as it is relatively fast to connect and provides acknowledgement in the protocol itself. A faster alternative may be sending a UDP packet, then an ACK from the server in UDP too as a reply. When your device gets reply, shuts down, otherwise retransmits for some time and then dies anyway to save power. You can store the info in flash, and retry to send it next time until packet is acknowledged.

Good luck.