Workaround for Short UDP Timeouts

Connectivity LTE Cat-M1 & NB-IoT
#1

Hello,

Our device, Ublox LARA R2 (LTE Cat1 device), uses UDP to communicate with our back-end server. When we started this project a while back, we were working with a SIM provider which had a UDP port timeout set to 10 minutes. That meant that the back-end had up to 10 minutes to reach out the device with UDP traffic before the UDP port was closed. With Hologram, the UDP timeout is 30 seconds for Open state and 60 seconds for Ready state. Very short and almost unworkable for us.

I had looked at Spacebridge and we might be able to set up PPP on the device and give it a go. But, there would also be some changes on the server.

Is there an easier solution?? Our “other” SIM card provider offers a VPN solution. Because the UDP traffic is no longer routed out in the “open”, they claim that the UDP ports would remain open indefinitely should traffic flow through a VPN. The great appeal is the fact that there wouldn’t be any changes required on the device or the server (other than config updates) to make this work.

Does Hologram offer a VPN solution which would allow us to continue to use UDP AND have the ports remain open for extended periods of time without constant traffic moving through?

One last point: we are in the process of moving the server code to AWS.

#2

Hi,

I just have some general questions about your setup.

Is there a particular reason the server needs such a long time to reply to the device? I guess what I am getting at is there a reason to use the current setup rather than something else?

You could use inbound SMS to deliver payloads, which is free. We have an API endpoint for convenience and it would probably be more reliable than UDP and you could send them at your leisure without having to maintain an open socket.

Its hard to know exactly what you are trying to do but I think practically all of our carrier partners have similar UDP timeouts. What your asking for is probably plausible (increasing timeout period) but I have questions if there aren’t better methods for going about what you are trying to accomplish.

#3

It’s not that the server needs 10 minutes to respond, ACKs from the server come back quick.

What we would like to do is allow the end user to request various things from the device on their own time and we would like the device be responsive. We do have a keep alive timer where a minimal payload gets sent by the device every 5 minutes unless other data flew through the socket, but still, to the end user, it appears that the device is awfully slow to act on requests.

We can’t make sure of inbound SMS right now quite the way we’d like it.

#4

would something like this work? https://www.hologram.io/guides/sending-messages-to-a-device

How do you handle dropped UDP packets? Since there is no way to be sure UDP packets get delivered if a user requests something from the device do you just regularly send packets until the device responds? If you are worried about responsiveness wouldn’t TCP offer a more reliable solution. Its more data but at least you can have assurances that things respond promptly/at all.

#5

There is application-level handshake in place to ensure the device gets to see every UDP frame. The server will retry every so often until it gets an ACK from the device saying I saw your message.

We started talking about TCP, just not quite ready to pull the trigger because of all that is involved. We’re still brainstorming…

#6

Can you comment on the UDP:TCP data ratio? I am not looking for an exact figure, just trying to determine whether this is 3x as much or more like 20% more.

Additionally, can you tell me what the TCP port timeouts are? They are 60 minutes with our other SIM provider.

Thanks.

#7

It generally depends. If you are sending a lot of small packets or constantly tearing down and restarting connections then TCP will probably be 3x the data usage. This link doesn’t have literally number comparisons but is kinda useful for getting an idea of pro/cons even though its talking about the protocols from a game design perspective: https://www.diffen.com/difference/TCP_vs_UDP

I can check what our TCP timeout is and get back to you.

Not to pry to much into the project but is my understanding correct that the cellular component is an end-user device that sends UDP packets to your server. How are you returning data to the cellular device? The server just responds to the UDP source?

#8

To answer the question about returning data… yes, it responds to the UDP source.

#9

Just reaching out to see whether you got a chance to check on the TCP timeout.

#10

Sorry I will pass that along to see what our timeout is

#11

Any updates?

#12

Sorry I havent been able to confirm I will pass it along to the carrier relations team since it would vary between our carrier partners.