I started integrating my hardware with the cloud these past few days while using a 3rd party SIM and I was quickly introduced to the keep-alive issues.
After some forum and doc reading, I figured that I would either use a shorter system keep-alive or add some periodic Particle.publish. Although this solved my immediate problem it still incurs in a data usage penalty.
So, my question is: Is it possible to add a system barebone datagram that only ensures that forwarding from network remains active if using 3rd party SIMs while also having the usual 23 minutes or so particle full 122 bytes to keep the cloud information up to date? Or maybe have a “best effort” intermediary keep alive that dosen’t require ACK.
The only way is to use the system keep-alive. The reason is that keep-alive is per-outbound port, and the only way to keep it alive is to send data on it, and only the system can send data on the cloud connection port, for obvious reasons.
The 23 minute keep-alive is a special agreement between the mobile carriers and Particle. With a 3rd-party SIM you’re at the carrier’s mercy, and it can be as low as 30 seconds.
Hi @rickkas7, thanks for your answer! I completely understand the reasoning behind it and you definitely don’t wanna other ppl poking the cloud port
I was just wondering if the addition of a lighter version of the current system keep-alive would be possible. Even having an alternative keep-alive with no ACK (best effort) could potentially half the data consumption while keeping the device available.
Only requiring a keep Alive ping every 23 mins saves tons of data over other cellular providers with much shorter Ping windows to keep alive which adds up quick based on the math I’ve done in the past.
Considering the eSIM using Particle I totally agree, I read the document regarding the transition from TCP to UDP using CoAp and the savings and the overall solution is great!
My request would be more focused on the cases where a 3rd part SIM is used, for example where a partner carrier is not present or 2G/3G is being phased-out.
There is no way to do a NO_ACK keep-alive on the cloud connection because the response is used to determine that the connection is still alive. Without it, you would keep breathing cyan forever without the ability to receive data from the cloud.
On a side note, what do you guys know about T-Mobile’s reducing the 3G coverage next year and forward? As far as US goes is there another 3G providers other than T-Mobile?
Live testing 30 second keep alive with 3rd party sim available in Scandinavia, even including the drastically increased amount of data, pricing was about the same (a bit lower) compared to Particle sim with the long keep alive period.
So, we are deploying devices in Rwanda where the Particle SIM carrier is Bharti Airtel. We tried using the Particle SIMs and raised numerous support tickets before giving up and going to a 3rd party SIM with the carrier who offers the best coverage in that country - MTN. We did this reluctantly and I have a standing request to be informed if Particle every adds MTN support.
That said, we have devices that monitor cold supply chains and need to publish every 20 minutes while shipments are in motion. It does not seem that MTN will allow a 20+ minute keep alive so we will need to periodically publish to keep the connection alive.
My question is this: What is the smallest possible amount of data we can consume and still keep the connection alive.
I can think of a few approaches but has someone already worked this out. For example would any of these consume markedly less data than the other?
Particle.publish(" ",PRIVATE);
Some call to the network such as synchTime();
An incoming API call where the device would simply answer with a “1”
Other ideas?
It looks like we can get around 10 minutes of keep alive but still, all this will add up over the course of a month.
What about an incoming Ping call? From the console, you can send a ping request to a device, and I would expect that to be the minimal amount of data you could send. I’m not sure if that is exposed by the cloud API, but it might work.
Even better would be if we had a ping (ICMP) call from the device itself.
The connection keep-alive keeps the port mapping alive. All cellular devices use carrier-level NAT. In order to get UDP packets back from the cloud a temporary port mapping is created. How long the carrier keeps this active will depend on the carrier and MVNO; the Particle SIM is unusually long at 23 minutes but some carriers may be as low as 30 seconds.
In order for the carrier to believe the mapping is still in use, the same pair of IP address and port must be exercised. Thus using other protocols such as direct UDP or ICMP (ping) won’t help.
Setting the Particle.keepAlive() is usually the best option, because it automatically resets when you send data.
Another option is is a one-character publish with NO_ACK.
Do you think that there’s a use case where the “connection” requirement (ability to the cloud to connected to the device - active forward) could have a fallback mode where you can reuse the session to send a message from the Device to the Cloud without the need to a constant active connection?
Using Particle SIM with the 23 minutes probably covers most cases, but an application where most if not all data actively flows from Device->Cloud and Particle SIM coverge is limited or problematic like @chipmc described, having an SYSTEM_MODE(SESSION_ONLY) could be quite useful.
A message sent in this mode would only require an ACK if the session was valid, or a NACK otherwise. The obvious trade-off is that Cloud->Device flow wouldn’t be reliable.
In order to take full advantage of the ability to wake on network, you need to be within the keep-alive, there’s no getting around that. In this state, the device will wake up with no handshake overhead and will not retransmit device vitals.
Beyond that, it is possible to resume session past the keep-alive, up to 3 days. The session can resume without a full handshake, and it often eliminates things like sending describe messages, so it does save data, but the amount of data is not zero.
After 3 days or if the power to the device was completely removed (retained memory cleared), a full handshake, describe messages, and device vitals will be sent again.
