MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol designed for low-bandwidth, high-latency networks—making it a natural fit for IoT applications. However, when MQTT is used over cellular networks, particularly at scale, understanding how keep-alive intervals and timeouts behave becomes crucial to ensure device connectivity and reliability. Surprisingly, there’s a lack of publicly available data on this topic.

In this article, we share our findings from internal tests using MQTT over cellular networks—highlighting how different configurations, networks, and brokers behave under varying conditions.

Cellular Networks and Timeouts: What You Need to Know

Contrary to common assumptions, cellular networks themselves do not implement a strict connection timeout. However, what typically happens is that idle connections are dropped after approximately 60 minutes, a behavior driven by APN (Access Point Name) parameters set by the home network.

For example, the Simplex Carrier 1 SIM—which supports roaming across 550+ networks globally—relies on the home network’s APN settings to define the behavior of the cellular session. Roaming networks do not override these defaults, meaning that devices on the same SIM experience consistent timeout behavior across different geographies.

The Impact of Cellular Instability

Cellular connectivity is inherently sporadic. Factors such as tower handoffs, signal loss, and temporary congestion can disrupt long-standing TCP sessions. This variability can influence how MQTT clients perceive the stability of their broker connection, especially with longer keep-alive intervals.

This issue is compounded when using cloud-hosted brokers, where idle connection timeouts are often implemented at the infrastructure layer.

MQTT Broker Behavior: Cloud vs. Local

We tested various MQTT client keep-alive intervals using a Simplex Carrier 1 SIM on both AWS-hosted HiveMQ instances and a local Mosquitto broker running on a Raspberry Pi.

Our key observations:

• AWS-hosted HiveMQ enforces timeouts aggressively. Any keep-alive interval over 300 seconds (5 minutes) frequently resulted in connection drops.
• Mosquitto brokers on local hardware (Raspberry Pi) demonstrated much more lenient behavior. Connections remained alive for up to 60 minutes or more, consistent with our understanding of the 60-minute cellular idle window.

Test Results Summary

Here’s a breakdown of our test results using various keep-alive intervals, broker types, and network access methods:

Note: AWS HiveMQ dropped MQTT sessions with keep-alive intervals longer than 300 seconds, while Mosquitto allowed long-running connections up to and sometimes beyond 60 minutes.

Key Takeaways

• Cellular networks don’t have fixed timeouts, but idle TCP sessions are usually terminated after ~60 minutes due to APN policy.
• Public cloud brokers (like AWS-hosted HiveMQ) often enforce connection timeouts around the 5-minute mark, requiring MQTT clients to set shorter keep-alives.
• Local brokers on edge hardware (e.g., Raspberry Pi) offer more generous timeout tolerance, aligning better with cellular APN behavior.
• Devices using MQTT over cellular should prefer keep-alive intervals ≤ 300 seconds when working with public cloud brokers to ensure connection stability.
• When deploying at scale, especially over a global roaming SIM like Simplex Carrier 1, test your MQTT client settings against your chosen broker to avoid silent disconnects.

Final Thoughts

The MQTT protocol is well-suited for cellular IoT—but real-world deployments must take into account both network-level idle timeouts and broker-level connection limits. At Simplex Wireless, we continuously test and validate configurations across networks and platforms to help our customers build resilient IoT solutions.