Correctly handle data communication failures

IoT Devices will inevitably encounter situations where network communication requests fail. When considering how to handle those failures, IoT Device Applications should be designed with the understanding that the IoT Communication Module’s normal behavior is to maintain a cellular connection.

Much like the previous section, when some kind of communication failure occurs, interrupting or forcing the module to behave differently than its normal operation is counterproductive for both the device and the network, and as recommended in TS.34_4.0_REQ_011, 012, 019, and 029, developers should take care how their device applications handle communication failures.

Applications should not retry failed communication requests indefinitely, but should eventually time out or abandon the request.

Similarly, frequent rebooting or reconnecting should be avoided, as communication failures may be due to a different part of the application other than the cellular network (for example, the application is unable to resolve DNS, or a server is temporarily offline), and forcing the communications module to restart is unnecessary and only serves to put additional strain on the network.

Instead, devices should check for issues elsewhere first and employ techniques for buffering or storing data internally, exponentially backing off between retries, or even waiting until “off peak” hours or days to transmit data when the network is not as busy, as recommended in TS.34_4.0_REQ_016, 018, and 025, before resorting to manual manipulation of the IoT Communications Module.

This also applies to use cases that incorporate other types of wireless technologies. For example, GNSS is a common choice for location-tracking applications, and many communications modules also support GNSS using the same receiver that is used for cellular connectivity.

However, as described in TS.34_4.0_REQ_034, loss of a GNSS signal should never result in restarting the cellular portion of the module, and device applications should leverage features like eDRX so that the receiver can be freed to evaluate GNSS signals without disconnecting or restarting the cellular module.

The same extends to devices that also have other connections, such as LAN (TS.34_4.0_REQ_036), WiFi (037), or connected sensors (038). The application should handle each communication separately, with each connection being independently restartable without having to restart the communications module.

In the worst-case scenario, when a device neglects these considerations and carelessly overrides the standard behavior of the communications module, MNOs may decide to blacklist the device outright to prevent further harm to the network.

Depending on the type of blacklisting, there may be no way to recover other than to replace the entire module or device.