4G DTU、 Instructions for heartbeat packets and registration packets in IoT transmission modules such as serial servers

Source: Modbus Chinese Network (modbus. cn) - a leading Modbus communication protocol technology community in China

This article: Heartbeat and Registration Packages for IoT Transmission Modules: Mechanism, Design, and Troubleshooting · Author: Modbus Technology Team · Released on July 1, 2026

Abstract: Heartbeat packets and registration packets are the core mechanisms for maintaining connection stability and device identity recognition in IoT transmission modules such as 4G DTUs, serial servers, and edge gateways. This article systematically explains the heartbeat mechanism from three levels: TCP KeepAlive, MQTT Keep Alive, and application layer custom heartbeat; Sort out the registration mechanism from DTU registration package to cloud platform device identity authentication, including parameter calculation formulas, code examples, and troubleshooting steps. Keywords: heartbeat packet, registration packet, 4G DTU, Keep Alive, MQTT heartbeat, TCP keep alive, device registration.

Insert a 4G DTU into the SIM card, configure the serial port parameters, connect to the server - the data is connected, do you think it's done. After one night, I found out the device was offline the next day, but the signal light was still on. Just restart it. It will be offline again in a few days.

This is a typical problem of maintaining long connections. In the IoT scenario, devices are distributed across the country, some in remote mountainous areas and some in basements. The communication link starts from the serial port of the device, passes through the 4G module of DTU, crosses the NAT gateway of the operator, and then reaches your cloud server through the public network. Every link on this chain may kill your connection, but you will not be notified.

This article explains the principles and practical applications of heartbeat and registration packages - not just concepts, but also provides parameters, code, and troubleshooting methods that can be directly used in projects.

1、 Why do long connections break

Before discussing heartbeat, first clarify how long connections are broken - different reasons correspond to different survival strategies.

Operator NAT timeout4G DTU uses a mobile network private IP (10. x.x.x/100. x.x.x) and can only access the public network through the operator's NAT gateway. NAT gateway sets a timeout period for idle connections in order to save resources. Typical values of the three major domestic telecom operators:

• China Mobile: 5 minutes
• China Unicom: Approximately 2-3 minutes
• China Telecom: Approximately 3-5 minutes

The NAT timeout time for different regions and package cards is not exactly the same, but it is generally between 2-5 minutes. If no packets pass through after this time, the mapping record on the NAT gateway will be cleared. Afterwards, when the server tried to send a packet to DTU, the NAT gateway no longer recognized the packet and directly discarded it - the device still appeared to be online (4G attachment was normal), but the data channel had already died.

Firewall/intermediate deviceThe exit firewall of enterprise networks usually also cleans up idle TCP connections. An industrial computer is connected to the enterprise intranet via WiFi and maintains a Modbus TCP connection with the cloud server. If there is no communication for half an hour, the Huawei firewall in the middle will mark the status of this connection as expired and release it. The server thinks the device is still connected, and the device thinks the server is still there - this is' connection spoofing '.

Equipment abnormal disconnectionOn site equipment power failure, 4G signal loss, switch restart - in these cases, the other end of the TCP connection will not receive FIN packets. If there is no disconnection signal on the fourth layer, the application layer cannot perceive it. If heartbeat detection is not used, the server will always assume that the device is online and dispatch tasks as usual, all of which will time out.

TCP semi open connectionOne end of the TCP connection has been closed (such as when the server is restarted), while the other end is still in a keep alive state without knowing. This is a standard 'semi open connection' scenario.

2、 Three layer keep alive mechanism: TCP KeepAlive, MQTT Keep Alive, application layer heartbeat

There are three levels of survival, corresponding to different scenarios and granularities.

2.1 KeepAlive at the TCP protocol layer - the lowest and least flexible layer

The TCP protocol stack comes with a KeepAlive mechanism. After activation, if there is no data transmission within the specified time, the operating system kernel will automatically send a probe packet (empty ACK) to the other end and wait for a response. If the other end is still alive, reply with an ACK; If it dies, close the connection after multiple unsuccessful detections.

The three key parameters of the Linux kernel:

net.ipv4.tcp_keepalive_time = 7200    # Idle time before the first detection(seconds)，Default 2 hour
net.ipv4.tcp_keepalive_intvl = 75     # Detection interval(seconds)，Default 75 second
net.ipv4.tcp_keepalive_probes = 9     # Detection frequency，Default 9 time

That is to say, by default, a TCP connection must be disconnected for 2 hours, 11 minutes, and 15 seconds (7200+75 × 9) before the operating system notifies the application layer that the connection is dead. This time is completely unusable for IoT scenarios - by the time you discover that the device is offline, the device's battery has been replaced twice.

Shorter parameters can be set for a single socket in the code (supported by Linux ≥ 2.6.37):

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)
# The following three parameters are required Linux 2.6.37+ and socket for IPPROTO_TCP
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPIDLE, 60)    # 60 Start detecting after seconds of idle time
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPINTVL, 10)   # each 10 Detect once per second
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPCNT, 3)      # 3 Second no response judgment disconnected

After this configuration, the discovery time of disconnection is 60+10 × 3=90 seconds.

But TCP KeepAlive has two fatal flaws。

Firstly, it can only detect whether the end-to-end TCP connection is alive, and cannot detect whether the intermediate devices (NAT gateway, firewall) between the ends have cleared the connection. The probe packet only flows between the TCP stacks of two endpoints, and may not refresh the NAT mapping entry when passing through the NAT gateway - that is, the TCP layer considers the connection to be normal, but NAT has already closed the channel.

Secondly, the default value of 2 hours is too long, and changing the parameters only applies to the current socket. If the machine is changed, it will return to the default configuration. Moreover, parameter modification requires root privileges, and the kernel of embedded devices (DTUs, serial servers) may not support dynamic modification.

So TCP KeepAlive can only serve as an auxiliary means in IoT scenarios and cannot replace application layer heartbeat.

2.2 MQTT Protocol Keep Alive - Standardized Application Layer Keep Alive

The MQTT protocol defines a 16 bit Keep Alive field in the CONNECT packet, measured in seconds. This mechanism is closer to application layer requirements than TCP KeepAlive:

• The client must send at least one control message (which can be any one of PULISH, SUBSCRIBE, PINGREQ, etc.) during the Keep Alive time.
• If the server (Broker) does not receive any packets from the client within 1.5 × Keep Alive time, it is considered that the client has disconnected, closed the TCP connection, and executed the Last Will message.
• Similarly, if the client does not receive any packets from the broker within the Keep Alive time, it should actively reconnect.

MQTT 5.0 goes further by allowing brokers to return Server Keep Alive values in CONNACK messages - if the broker does not accept the Keep Alive suggested by the client, it can override it with its own value, and the client must comply with the value returned by the broker.

Key value selectionMQTT's Keep Alive cannot be set too large or too small. Too big, the device was offline for a long time before the Broker discovered it; Too small, frequent heartbeat packets consume SIM card data. In actual projects, MQTT's Keep Alive is usually set between 60-120 seconds. If the device is battery powered (NB IoT scenario), it can be relaxed to 300-600 seconds.

Difference from TCP KeepAliveMQTT's Keep Alive is an application layer protocol behavior, where PINGREQ packets are encapsulated and sent within TCP packets. The NAT gateway will refresh the mapping entry when it sees a TCP packet passing through. That's why MQTT's Keep Alive can solve NAT timeout issues, while TCP Keep Alive may not.

2.3 Application Layer Custom Heartbeat - The Most Flexible and Requires the Most Design

If your device does not use MQTT and uses bare TCP/UDP transparent transmission (Modbus TCP, custom binary protocols, etc.), you will need to design your own application layer heartbeat. This is the most common heartbeat packet concept in 4G DTUs and serial servers.

Design Principles：

1. The heartbeat packet should be as small as possible.Traffic is money. The simplest heartbeat packet can be one byte - for example0x48(ASCII 'H'), or the fixed string 'Q'.
2. The heartbeat interval should be less than the NAT timeout.The shortest NAT timeout for domestic operators is 2 minutes, so the heartbeat interval is generally set to 60 seconds or shorter. Conservative suggestion is 30-60 seconds.
3. The server should reply with a heartbeat.Unidirectional heartbeat can only let the server know that the device is alive, but the device does not know if the server is alive. Bidirectional heartbeat (device sends, server responds) allows both ends to detect the status of the other end.
4. Trigger reconnection after N consecutive failed heartbeats.It's not about losing a heartbeat and then stopping - occasional packet loss is normal at the network level. Usually set to trigger a reconnection process after 3 consecutive heartbeats with no response.

Heartbeat Example of AIRIOT PlatformThe device sends the character "Q" at regular intervals, and the platform immediately replies with "A" upon receiving it. The device determines whether the connection is normal by whether it receives "A" - this design is simple and effective, and the implementation cost on 4G DTU is extremely low.

Calculation formula for heartbeat interval：

heartbeat interval < NATtimeout period × safety factor
safety factor = 0.6 ~ 0.8

If the operator NAT timeout is 5 minutes (300 seconds), take a security factor of 0.6, and the heartbeat interval is ≤ 180 seconds. Considering occasional network jitter, setting it to 60-90 seconds is more secure in actual projects.

3、 TCP KeepAlive vs Application Layer Heartbeat: When to Use Which

There is no standard answer to this question, it depends on your scenario.

Suggested combination strategyIn the production project, both TCP KeepAlive (as the underlying fallback) and application layer heartbeat (as the main detection) are enabled simultaneously. Set the TCP KeepAlive parameter to be shorter (60 seconds idle+10 second interval+3 probes), and set the application layer heartbeat to 30-60 seconds. Even if the application layer heartbeat is not sent out due to a bug, TCP KeepAlive will still find the connection disconnected after 90 seconds.

If your device must use UDP (such as the registration mode of some DTUs), then TCP KeepAlive is completely useless - you can only use application layer heartbeat.

4、 Registration Package: Let the Server Know Who I Am

Heartbeat solves the problem of 'I am still alive', while registration packages solve the problem of 'Who am I'.

4.1 Essence of Registration Package

In DTU and serial servers, the registration packet is the first packet of data sent by the device after establishing a TCP connection, used to declare its identity to the server. The server associates the current TCP connection with pre registered device records based on the content of the registration packet.

A typical DTU registration process:

1. DTU power on, dial-up, and attach to 4G network
2. DTU connects to the specified port of the server via TCP
3. After the connection is successfully established, DTU immediately sends a registration packet (which can be a string of custom characters or IMEI/ICCID)
4. Server parsing registration package, identifying device identity, updating device online status
5. Registration completed, normal bidirectional data transmission begins

4.2 Two Timing for Sending Registration Packages

Some DTUs support two registration package sending methods:

Send once during connectionOnly send when a TCP connection is established. Normal data transmission thereafter no longer includes registration information. This applies to scenarios where servers manage device identities by connection - one TCP connection corresponds to one device, and the identity is determined once the connection is established.

Attach before each package of dataAttach the registration package before each transparent data transmission. Suitable for scenarios where multiple devices are connected through the same serial server or gateway - the server needs to determine the data source device based on the registration information in each packet of data. The disadvantage is that it increases the cost per packet of data.

Taking someone's DTU as an example, using the configuration method of registration package:

• Check 'Enable registration package'
• Choose sending method: 'Send once upon connection' or 'Add before each packet sent to the server'
• Customize registration package content (such as01Representing device 1,02Representing device 2)
• The data format received by the server is:注册包 + 透传数据

4.3 Data Content Design of Registration Package

The content of the registration package depends on your backend architecture. Common practice:

Using IMEI as the unique identifier for the deviceThe IMEI (International Mobile Equipment Identity) is a 15 digit number that is unique worldwide and cannot be changed by burning it in a 4G module. When DTU starts, it reads the IMEI of the module and sends it as a registration packet to the server. The advantage is that it is naturally unique and does not require human allocation; The disadvantage is that the IMEI length is 15 bytes. If extreme data saving is required, short IDs (2-4 bytes) pre allocated by the platform can be considered.

Use the pre assigned serial number on the platformWhen registering a device on the cloud platform, the platform generates a unique serial number (which can be a self added ID or a short hash of UUID). Write this serial number to the DTU through the configuration tool, and send it when the DTU is connected. The advantage is that the serial number can be controlled (such as encoded by region) and the length is short; The disadvantage is that it requires a configuration and distribution process.

Using ICCIDThe ICCID of the SIM card is also a 20 digit number, unique. But generally not recommended - because the SIM card may be replaced, and the device should not become "another device" due to card replacement.

4.4 The relationship between device registration on cloud platforms and DTU registration packages

In standard IoT platforms such as Huawei Cloud IoTDA or Alibaba Cloud IoT, device registration is an independent process:

1. First, create a product on the platform (define the data model of the device)
2. Then register the device (platform generates Device ID and Device Secret)
3. Write these credentials into the firmware or configuration file of the device
4. When the device is started, an authentication connection is initiated to the platform with the Device ID and Secret (usually through MQTT's Username/Password field or X.509 certificate)

In this process, the "registration package" of DTU is actually the device authentication information corresponding to the platform. For example, the AIRIOT platform requires devices to send a serial number as soon as a TCP connection is established, which is essentially a simplified version of the device authentication protocol.

If your backend server is developed by yourselfThe registration agreement is entirely designed by you. The core requirements are two-fold: unique device identity and server verification of identity. The simplest solution -4G DTU is registered with IMEI and signed with a fixed key (HMAC), which is sufficient to meet most non-financial level security requirements in industrial scenarios.

5、 Complete parameter recommendation and practical configuration

5.1 Recommended values for heartbeat parameters

5.2 Recommended TCP KeepAlive Parameters for Linux Server Side

在 /etc/sysctl.confIn the middle:

net.ipv4.tcp_keepalive_time = 120
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 3

thensysctl -pApplication. Combined with the application layer heartbeat (such as a 60 second interval), the two layers keep each other alive.

5.3 Example of actual DTU configuration

The following is a typical 4G DTU configuration scheme (taking the USR-G780 as an example):

心跳包：启用
心跳周期：60 秒
心跳内容：Q（自定义字符串）

注册包：启用
注册包发送方式：连接时发送一次
注册包内容：IMEI（使用设备 IMEI 作为唯一标识）

连接类型：TCP Client
服务器地址：your-server.com
服务器端口：8001
断线重连：启用，间隔 10 秒，最多重连 30 次

Server side corresponding logic:

1. Received TCP connection request → Accept connection
2. Wait for 5 seconds to receive the registration package → Extract IMEI, check the matching device list in the database → Update the device's online status to Online
3. No registration package received within 5 seconds → judged as illegal connection, close socket
4. After successful registration, start the heartbeat timer and expect to receive a "Q" every 60 seconds → reply with "A"
5. Three consecutive heartbeat cycles (180 seconds) without receiving "Q" → device offline is determined, triggering reconnection/alarm

6、 Common pitfalls of heartbeat and registration

6.1 NAT timeout and heartbeat cycle mismatch

The most common issue is that the heartbeat cycle is set to 5 minutes, and the operator NAT timeout is 2 minutes. The result is that every heartbeat interval, NAT has been disconnected, heartbeat packets cannot be sent out, and the device is always in an infinite loop of "connect → disconnect after 2 minutes → reconnect after heartbeat timeout → connect → disconnect after 2 minutes".

Diagnostic method: Look at the connection establishment time and disconnection time of the same device on the server side. If the disconnection time establishment time is almost always a fixed value (such as 120 seconds), it is basically a NAT timeout problem.

Solution: The heartbeat cycle is less than 120 seconds.

6.2 Registration package not sent immediately after connection establishment

After establishing a TCP connection with DTU, if transparent data is sent first instead of registration packets, the server cannot recognize which device the data comes from - especially when multiple devices share the same server port. If the first packet received is not a registration packet, the server can only discard or close the connection.

It must be ensured that the registration package is sent out as quickly as possible after successful socket connection.

6.3 Bidirectional heartbeat only performed on one side

The device is heartbeat and the server is not responding - the server knows that the device is alive, but the device does not know if the server is still alive. If the server no longer responds to heartbeats due to program bugs or network issues, the device may continue to wait until the business data transmission timeout before realizing that something has happened.

Bidirectional heartbeat allows the device side to actively detect server abnormalities and trigger reconnection. This is very important for DTU devices that are distributed throughout the country and are unmanned.

6.4 Cross platform differences of TCP KeepAlive

Windows, Linux, FreeRTOS, and LwIP have different default values and configurable parameters for TCP KeepAlive. Linux defaults to 720000 seconds, Windows defaults to 7200000 milliseconds (2 hours), and LwIP (embedded TCP protocol stack) also defaults to a large duration. Never rely on default values.

6.5 Registration package content not verified

If the registration packet is transmitted in plaintext (such as directly sending the IMEI), it may be captured and tampered with on the network link. For scenarios with high security requirements, the registration package should include at least one digest or signature. The simplest approach is for the device to use a pre-set symmetric key to create an IMEI timestamp with an IMEI, and the server will only accept registration after verifying that the IMEI passes.

7、 Checklist

When DTU frequently goes offline, troubleshoot in this order:

The concept of heartbeat and registration package is very simple - send a package at a fixed time and indicate who you are. But in reality, the details all lie in parameter selection and prediction of failure modes. The numbers given in this article (30 seconds, 60 seconds, 120 seconds) are not arbitrary - they are based on the balance point between NAT timeout of the three major domestic operators, power constraints of 4G modules, and server resource overhead. If the scenario of your own project is different, capture and verify the package yourself in the testing environment.

Let's talk if there are any issues.