Select appropriate protocols

In many use cases, developers may decide to implement a heartbeat or keep-alive mechanism whereby an IoT Device sends a simple message at regular intervals to indicate that it is operating normally.

When implementing such a mechanism, it is critical to plan the implementation according to the underlying communication protocol.

For example, when using a connection-oriented protocol like TCP, the heartbeat interval should be set just below the connection timeout of the protocol.

Setting a faster heartbeat serves no purpose other than to generate excessive messages and waste network resources, because a stopped heartbeat does not automatically indicate that the device is offline. In fact, only when the connection times out can the device correctly be considered offline.

This also applies to using TCP keep-alive to keep the connection open even when no data is being transferred. Here, TS.34_4.0_REQ_007 defines a default polling interval of 29 minutes for devices using TCP keep-alive.

Protocol selection also depends greatly on which connectivity technology you want to use. The most popular example is NB-IoT, which by design has very high latency (on the order of 30 seconds or more) in order to be extremely power-efficient, and automatically repeats data transmission multiple times in order to achieve a wider coverage (known as Coverage Enhancement).

Because of this design, connection-oriented protocols like TCP (as well as TCP-based protocols like MQTT and HTTP) are the wrong choice, since their timeout and retry mechanisms conflict with NB-IoT’s latency and message repeating behavior and can result in hundreds or thousands of unnecessary messages.

As proposed in TS.34_4.0_REQ_006 and 031, IoT Devices communicating over NB-IoT should not use TCP at all.