BACnet Request Retry

Overview

The BACnet Request Retry diagnostic identifies instances where a BACnet client resends a Confirmed Request message due to a missing or delayed acknowledgment. This behavior is often indicative of network congestion, device unresponsiveness, or misconfiguration (e.g., APDU timeout values). 

Identifying retries is critical for maintaining efficient communication between devices and ensuring the best possible performance of the building automation system (BAS). It also provides critical insight into potential failure points across routers, or device links that can affect system stability.

How The Diagnostic Works

The diagnostic analyzes confirmed requests and matches them with subsequent retries from the same source to the same destination with the same Invoke-ID. It identifies whether a retry occurred and calculates:

A low retry ratio (under 25%) typically indicates that the bottleneck is minor or intermittent, while a high retry ratio (above 50%, and especially closer to 75%), it suggests a severe bottleneck or network interruption where multiple retries are needed to get an acknowledgment, if at all. 

How to Fix It

Users are encouraged to correlate findings from this diagnostic with other network-level diagnostics for a more complete picture, such as:

• Unacknowledged Request Diagnostic. Comparing communication paths and the respective diagnostic ratios in the Request Retry diagnostic and Unacknowledged Request can help determine how severe the network bottleneck is.  When both diagnostics highlight the same communication path or destination, it significantly strengthens the case for an unresponsive or overloaded target device.

• Slow Response Time Diagnostic. By comparing retry events with elevated response times on the same communication path, users can determine whether the root cause is congestion, latency, or insufficient APDU timeout configuration.

When all three diagnostics—Request Retry, Unacknowledged Request, and Slow Response Time—flag the same destination, it's credible evidence of a communication bottleneck. 

This is often seen in cases of:

• Overloaded BACnet routers due to excessive broadcast or excessive unicast traffic through it or busy handling higher priority tasks (e.g. HMI)

• Overloaded devices due to excessive broadcast or excessive unicast traffic to it or busy handling higher priority tasks (e.g. HMI)

Troubleshooting Flow

1. Start by identifying paths where confirmed requests are being resent.

2. Cross-reference with Unacknowledged Request diagnostic to confirm if all responses were entirely missing. If so, the target/destination device may be offline or unreachable. The retries and unacknowledged requests may not be due to a bottleneck but rather a complete offline segment.

3. Check Slow Response Time diagnostic results to see if the latency was high enough to cause retries.

4. Use device role information (e.g., BACnet Router) and traffic pattern diagnostics to isolate congestion points.

5. Once a bottleneck has been pinpointed, consider reducing amount of traffic to and through the segment, such as broadcast traffic and targeted messages to/through the device/route.

By taking this layered diagnostic approach, users can move beyond symptom-level alerts and directly isolate true communication bottlenecks in the BACnet network.