Latency Benchmarks for Private 5G Networks

If you’re judging private 5G for industrial use, average latency is not enough. What matters is whether the network can hold packet delay inside a tight time window when traffic loads go up.

From the studies covered here, I’d boil it down like this: private 5G can suit monitoring, SCADA, AGVs, mobile robots, and some safety functions today, but it still falls short for hard real-time control such as sub-1 ms robot or PLC timing. Lab tests showed below 1.0 ms downlink median latency with a 99.9th percentile near 1.1 ms, but site tests were much higher, with figures such as 3.9 ms uplink, 4.6 ms downlink, 11.36 ms RTT, and 20.4 ms RTT depending on setup, load, and what was included in the path.

If I were assessing a deployment, I’d focus on these points first:

• Check tail latency, not just averages
  A network can look fine at the median and still miss timing at the 99th or 99.9th percentile.
• Separate radio latency from end-to-end latency
  VPNs, PLC logic, transport, and core placement can add far more delay than the radio link itself.
• Expect load to change the picture
  In one factory-floor test, mean downlink latency moved from 4.6 ms at low load to 25 ms under heavy traffic, and up to 53 ms without QoS prioritisation.
• Match the benchmark to the use case
  SCADA and monitoring can fit inside 7–28 ms results. E-stop functions were kept under 99 ms at the 99th percentile in one system trial. But isochronous control still does not fit current benchmark ranges.
• Design choices matter
  An on-site core, edge-hosted control, TDD tuning, and QoS settings can shift latency by a wide margin.

Here’s the short verdict:

So when I look at private 5G latency numbers, I don’t ask, “What’s the lowest figure in the lab?” I ask, “What happens on site, under load, at the tail, across the full path?” That’s the test that tells you whether a network will hold up in day-to-day factory use.

Recent private 5G latency benchmarks: lab results and industrial trials

Controlled lab studies reporting sub-millisecond results

In a controlled 5G SA n79 testbed, Adamuz-Hinojosa et al. recorded median downlink latency below 1.0 ms for small payloads, with the 99.9th percentile at about 1.1 ms. That’s the kind of result people like to quote, but it’s a best-case number, not a normal industrial starting point. As payload size increases, traffic builds, or even a small amount of interference appears, latency climbs fast.

Smart factory and campus deployments under realistic load

Once you move from a tidy lab setup to a working site, the picture changes. Latency tends to jump unless QoS settings and edge placement are set up with care.

At Silicon Austria Labs in Linz, Austria, a 2023 test campaign on a 38 m × 38 m factory floor used a 5G SA testbed in band n78 at 3.41–3.49 GHz. It recorded mean one-way latencies of 3.9 ms uplink and 4.6 ms downlink at low load, with 99.9997% reliability for latency below 14 ms during a one-hour test. Under maximum downlink load, mean latency rose to 53 ms without QoS prioritisation.

At Helmut-Schmidt University in Hamburg, a July 2024 trial linked a private 5G SA network at 3.7–3.8 GHz using Ericsson equipment with IO-Link Wireless. The goal was to test a decentralised software-based PLC for intralogistics. Over a 20-hour test, the average round-trip time between 5G routers was 20.4 ms. The 99th-percentile end-to-end SFRT for the wireless emergency stop stayed below 99 ms, but the worst-case estimate reached 149.6 ms once VPN tunnel and PLC overhead were added.

In Bristol, UK, researchers at Toshiba Europe Ltd. tested a hybrid 5G–TSN setup in 2024 using a private 3.8–4.2 GHz band. The average RTT came in at 11.36 ms. One point stood out: cutting TSN base periods from 200 ms to 40 ms led to more predictable behaviour in a standard 5G setup.

Benchmark comparison table across studies

Architecture and load matter more than radio conditions on their own. The range in these figures comes from different test setups, traffic levels, and latency definitions, which the next section breaks down.

sbb-itb-ebe3925

How latency is measured and why benchmark numbers differ

Measurement setups: traffic tools, clock sync, and segment-by-segment tracing

The gap between lab and field results often comes down to how latency is measured. The benchmark table in the previous section shows a broad spread of figures, and that spread is not just about radio conditions. In many cases, teams are measuring different things in different ways. So before putting benchmark numbers side by side, you need the method behind them.

Most studies rely on traffic tools such as iperf3 or IRTT (Isochronous Round-Trip Tester). For latency work, UDP is the better choice than TCP. TCP retransmissions and windowing can skew the result and blur the actual delay. IRTT is especially handy for industrial tests because it sends packets at fixed intervals, which matches periodic control traffic more closely.

For industrial use, one-way delay is often the metric that matters most. But there’s a catch: it only works well when both ends share a clock. Accurate one-way delay measurement usually depends on sub-microsecond clock sync through Precision Time Protocol (PTP/IEEE 1588), gPTP, or GNSS-disciplined clocks. In one Silicon Austria Labs campaign, PTP synchronisation precision stayed below 2 μs during hour-long tests using ptp4l with hardware timestamps. That detail matters. Software timestamps can pick up operating-system jitter, so if someone is making sub-millisecond claims, hardware timestamping is the safer starting point.

Another useful approach is per-segment tracing. Instead of treating latency as one single number, it splits the full path into radio, transport, and core segments. That shows exactly where delay is added, which is what operators need if they want to fix a live setup. In a Helmut-Schmidt University testbed, the full path was split into wired IO-Link (0.7 ms), wireless IO-Link (1.5 ms), and 5G/Ethernet/PLC processing (31.1 ms). The result was clear: the radio link was not the main bottleneck. Once the delay is mapped across the path, the next job is picking the right metric to judge it.

Metrics that matter: median, tail latency, jitter, and load effects

A single average doesn’t tell the full story. It’s better to report median latency, tail latency, and jitter together. In industrial systems, tail latency often matters more than the median, because timing failures tend to happen at the edge of the distribution, not in the middle. University of Granada work shows that TSN scheduling should be based on the maximum observed 5G delay, using a high-percentile metric.

Load makes this even more important. As network utilisation rises, queuing delay can push the top end of the latency distribution up much faster than the median. So a network may still look fine on average while missing timing targets at the worst moments. In one Silicon Austria Labs result, mean downlink latency rose from 4.6 ms to 25 ms under heavy traffic load, even with QoS prioritisation enabled.

TDD frame configuration also changes the result, yet many papers leave out the TDD pattern. A pattern with more uplink slots can cut UL latency, but that often adds delay on the downlink side. Uplink latency is also shaped by the Buffer Status Report process. Enabling Full Buffer Status Report (Full BSR) can reduce mean UL latency because the base station can pre-allocate resources instead of waiting for repeated scheduling requests. In plain terms, these setup choices can decide which industrial workloads a deployment can handle and which ones it can’t.

Methodology comparison table

These measurement choices shape what the benchmark numbers actually mean in practice. A figure that looks strong in one setup may say very little about another unless the tools, synchronisation, traffic profile, and reported metrics line up.

What the findings mean for industrial applications

Use cases that private 5G can support today

The benchmark data shows a pretty clear split between what private 5G can handle now and what still sits outside its reach.

Remote monitoring and SCADA fit well within current performance. Results in the 7–28 ms range line up with SCADA-style monitoring needs. AGVs and autonomous mobile robots also look like a good fit, with emergency-stop performance coming in at roughly 100 ms. In both cases, the main limit is not raw radio speed. It’s where the core network sits and where the control logic runs.

Private 5G still has a hard time with isochronous control, where sub-millisecond PLC-to-actuator timing is needed. A University of Granada study found that 5G-induced jitter disrupts TSN scheduling, which backs up the point that isochronous workloads are still beyond current deployments. Right now, those jobs still belong on wired infrastructure.

Where architecture makes the biggest difference

The same radio can behave very differently once edge placement, scheduling and traffic load change. The range seen across benchmark studies came from locality, edge placement and scheduling choices, not just radio conditions. Three design decisions matter most.

• Place the core on-site. A full Non-Public Network setup gives the lowest latency and keeps traffic local, so you avoid an extra round-trip to a remote data centre.
• Host applications at the edge. Putting control logic, such as a virtual PLC, on a local edge server removes one full 5G traversal from the control loop. That translates straight into lower response times.
• Tune TDD pattern and QoS. Adjusting TDD slot configuration and setting Allocation and Retention Priority (ARP) levels helps protect critical traffic when the network is under load .

Industrial use case table: latency targets and benchmark evidence

The farther a use case is from hard real-time demands, the safer the fit for current private 5G. At that point, deployment design becomes the next thing to get right.

Design guidance and conclusion: turning benchmarks into deployment decisions

Design priorities for lower and more predictable latency

The benchmark results point to a short list of deployment choices that have a big impact on day-to-day latency. The main issue isn’t just low average latency. It’s whether latency stays steady when the network is busy, across the full end-to-end path, especially at the tail.

Start with SA architecture, an on-site UPF, and edge-hosted control so traffic stays local and avoids extra hops.

Two setup choices can also change uplink performance in a big way:

• Full BSR can cut uplink scheduling overhead and lower UL latency.
• An uplink-heavy TDD pattern can reduce UL delay, but it also pushes DL delay up, so the best option depends on your traffic mix.

Antenna placement still plays a big part in metal-heavy industrial settings.

Load testing is where the gap between lab numbers and live performance starts to show. High traffic can push mean downlink latency from 4.6 ms to 25–53 ms, so don’t stop at average figures. Check the 99th or 99.9th percentile under load.

These are the same levers a lab kit or on-site deployment should test before rollout.

Applying the research with Firecell private 5G solutions

Firecell‘s lab kits and on-premise private 5G deployments give teams a way to test TDD, QoS and edge placement before rollout.

Conclusion: the benchmark signals industrial teams should act on

The studies reviewed here tell a clear story. Controlled campus measurements report mean one-way over-the-air latency as low as 3.9 ms uplink and 4.6 ms downlink under low load. But end-to-end performance in live deployments depends a lot on where the core and applications sit. For automation workloads, jitter and tail latency matter far more than averages.

Before committing budget, test under realistic load, measure high-percentile latency, and make sure the benchmark method matches the use case.

Network testing for 5G private networks

FAQs

Why is tail latency more important than average latency?

In industrial settings, tail latency matters more because deterministic operations live or die by timing. Systems like autonomous mobile robots and production-line equipment need packets to land inside strict time windows.

Average latency gives you a rough picture, but it can mask spikes that throw synchronised control loops off beat, add jitter, and break determinism. For safety and reliability, these systems have to meet latency limits even under worst-case conditions.

What should I measure in an on-site private 5G latency test?

Measure one-way OTA latency to judge end-to-end performance. Also check packet-level metrics, including downlink and uplink throughput.

For industrial deployments, add jitter and signal data such as RSRP heat maps for coverage. If you’re using Time-Sensitive Networking, measure delay between switches as well. It also helps to review quality of service settings.

Which industrial applications still need wired links instead of private 5G?

Some industrial setups still need wired links when extreme determinism matters most. That’s especially the case in jobs that need sub-microsecond accuracy and tightly bounded latency, like certain closed-loop process automation systems.

In those situations, wired connectivity is still the go-to choice because it keeps the level of synchronisation that wired fieldbuses have long provided.

Related Blog Posts

• Edge Computing vs Cloud: Latency Impact
• 5 Latency Optimisation Tips for Private 5G
• Private 5G for Robotics: Latency Insights
• 5G Handover for AMRs: Key Metrics to Track