Heartbeat timeout versus QOS 1 for telematics devices on 3G

[Randy Nuss]

We have telematics devices which constantly transmit packets on 3G cellular networks.  We cannot lose any packets, but chose to keep QOS=0 to keep bandwidth lean.  A timeout of 1-minute is utilized to trigger re-sends.  This generally works well.  In poor coverage areas we see a lot of duplication.  A particularly bad scenario seems to be when a cell switchover occurs (our devices are mobile).  We have seen 70% duplication in such a scenario.

We have not tried QOS=1, and I am wondering if this would be more appropriate.  Anyone with experience using MQTT for telematics?

[Paul Fremantle]

Randy

Two thoughts.

1) QOS1 won't necessarily prevent duplication though it will probably produce less than the current scheme.

2) I think the main question is how big your messages are: if they are very small, your current model is probably more bandwidth efficient. If the messages are bigger, then the QOS1 model will do a better job. 

Of course if you require every message to get through, QOS1 is definitely the choice.

Paul

On 12 December 2014 at 20:10, Randy Nuss <randal...@gmail.com> wrote:

We have telematics devices which constantly transmit packets on 3G cellular networks.  We cannot lose any packets, but chose to keep QOS=0 to keep bandwidth lean.  A timeout of 1-minute is utilized to trigger re-sends.  This generally works well.  In poor coverage areas we see a lot of duplication.  A particularly bad scenario seems to be when a cell switchover occurs (our devices are mobile).  We have seen 70% duplication in such a scenario.

We have not tried QOS=1, and I am wondering if this would be more appropriate.  Anyone with experience using MQTT for telematics?

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at http://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

--

Paul Fremantle

Part-time PhD student - School of Computing

email: paul.fr...@port.ac.uk, pa...@fremantle.org

twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org

CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair, Apache Member
07740 199 729

[Frank Pagliughi]

I've been playing around with using GPRS modems, and I wouldn't have even thought to use QOS=0 due to worries of reliability. My worry was not with the bandwidth, since the ACK packages are pretty tiny, especially compared to our data. My worry was more with the latency of the replies, considering that this is a battery-powered device and the modem is a power hog compared to the rest of the system.

But the first-order optimization was as Paul mentioned - bundle multiple data packets into a single published message. That helps on both counts.

Frank

[Randy Nuss]

We are bundling data into a packet once per second.  Average packet size would be around 1500 bytes.  We are able to compare logs on the device side with the server side, and all data gets to the server.  So the large amount of duplication seems very unnecessary.  

One other consideration is that our goal is to display data close to real-time.  I believe that's another reason the developer chose to go with QOS=0.  So I'm not sure what 'ACK' he's waiting on.  My understanding is it's the MQTT heartbeat.  It sounds like it would be worth at least trying QOS=1 and comparing.

[Frank Pagliughi]

With QOS=0, the client sends a message and forgets about it. Since it's riding on top of a TCP connection, there's a pretty good chance that it will arrive at the broker, unless the network connection is dropped in the middle of the transmission. But you don't "know."

With QOS=1, the broker sends an ACK back to the client for each individual message. Only after receiving the ACK does the client consider the publish "transaction" complete. If the client doesn't receive the ACK after a reasonable amount of time, it re-sends the original message. This is normally done by the client library without any additional work for the app.

If the ACK got lost or the server took too long to send it, the client will re-transmit the message, and this second copy of the message will arrive and be sent to the subscribers. If this second copy is acceptable, then QOS=1 is fine. But if you need to make sure that one-and-only-one copy of each message arrives, then consider QOS=2. This involves another pair of handshake messages, but might be worthwhile.

So QOS=0 makes no promises; QOS=1 insures that individual messages arrive properly one or more times; QOS=2 insures that messages arrive once and only once.

But your solution is the best thing: Try QOS=1 and compare.

Frank