TCP Socket Keepalive

Astra Telematics IoT devices, like many others, communicate with the host server using TCP sockets.  Once the socket has been opened, the connection is maintained between the IoT device and the server, so that either side can send and receive data at any moment.  A TCP socket can therefore be described as a “connection” which needs to first be established and remain open for communications to flow.  Its important to note that in mobile network communications, the mobile device must open the TCP socket, and hence the connection is managed from the IoT device.

Our devices are used in applications where real-time communication is important (e.g. moto-sharing / mobility), and hence they are designed to constantly maintain the TCP socket connection in an open state, so the IoT device is ready to receive a command from the server at any time (e.g. when a user elects to use a vehicle and start a journey).  On the other hand, mobile network operators need to manage their resources by closing down idle connections, and this is typically done after 10-15 minutes without any data exchange between the mobile device and the remote server.  Other scenarios can also cause the TCP socket to be closed by the network operator, such as cell handovers.  In many cases, the mobile (IoT) device will receive an indication that the TCP socket has been closed, and will attempt to re-establish the connection, but in some cases, the socket is closed “quietly” and the IoT device still thinks that it is open and ready for communication.  During this period, the remote server cannot communicate with the IoT device, which can clearly cause problems in many applications.  The true state of the TCP socket is eventually discovered only when the IoT device tries to send data to the server.

Here is where we get into the topic of TCP socket keepalives, which aim to verify the state of a socket and help to maintain the connection between the mobile IoT device and the remote server.  A common solution is to regularly send data, which is an effective way to verify socket status and force a new connection where necessary.  The downside of this solution is that it consumes a significant amount of data, especially when the keepalive data is sent at short time intervals, 24x7x365.  The data is of little value, since (in the idle state) nothing has happened and nothing has changed.  A more efficient option is to send a single byte of data purely for keepalive purposes.  This can be done from either side of the connection (mobile IoT device or server), but its best done from the mobile device, since that side of the connection has the capability to re-establish the connection if and when necessary.  Astra devices have the capability to send single byte keepalives using the PING-PONG option defined in our $TCPT TCP socket timeout configuration.  This feature can be used to enable a keepalive to be sent from the Astra device after a defined period of socket inactivity, after which 1 of 3 things can happen:

1. If the TCP socket has been closed “quietly”, at the point of attempting to send data, the mobile device will realise that it is closed (the GSM/LTE module will give an appropriate result code).
2. The keepalive can be sent, but no reply received from the server, within the specified timeout (defined in $TCPT).
3. The keepalive can be sent and a reply received from the server.

In the first 2 scenarios, the Astra device will attempt to re-establish the TCP socket connection, and in the 3^rd scenario, we have successfully verified the connection and both sides have validated the connection status.

Many GSM/LTE modules have an additional option to manage TCP socket keepalive within the TCP stack, but in our experience, these are not effective, and whilst we typically enable this feature, we do not rely on them.