DEV Community

Cover image for Measuring End-to-End Latency for Robots and Cameras Over 5G (Without RF Gear)
Yacine Si Tayeb
Yacine Si Tayeb

Posted on

Measuring End-to-End Latency for Robots and Cameras Over 5G (Without RF Gear)

#tutorial #resources #coding #5g

Who it’s for: edge devs, robotics/video teams, SREs

What you’ll get: a repeatable lab you can run on a laptop (no radios), the exact metrics to collect, acceptance targets you can defend, and a simple “latency budget” you can use to argue trade-offs with stakeholders.

Why measure this way?

Robots and camera uplinks don’t fail because the spec was wrong—they fail because your encode/decode, queues, and network jitter don’t line up under real workload.

You can surface those issues without touching spectrum: emulate the 5G user plane with containers, drive realistic traffic, and measure application-level latency. When you later move onto a real 4G/5G testbed, you’ll bring the same tests and thresholds. Same harness in lab and field = honest comparisons.

What “good” looks like

Tele-op/AGV control loops

  • One-way network path for control: ≤ 20–50 ms (pick for your safety envelope)
  • Jitter p95: ≤ 5–10 ms
  • Loss: ≈ 0%
  • If you only have RTT, budget ≤ 40–100 ms RTT with tight jitter.

Live camera uplink (1080p30 “low-latency”)

  • Glass-to-glass: ≤ 150–250 ms
  • Network one-way: ≤ 30–60 ms
  • Encode / Decode / Render each: ~30–60 ms

These are sane starting points. Tighten once your robot/camera vendor signs off.

The RF-free lab (what to spin up)

You’re not proving RF performance; you’re validating the end-to-end behavior of your workloads over a 5G-like core + user plane.

  • Core: Open5GS (AMF/SMF/UPF with WebUI + Mongo)
  • RAN/UE sim: UERANSIM (gNB + UE)
  • Workloads:
    • a tiny UDP echo service for control-loop RTT
    • GStreamer sender/receiver for low-latency H.264
    • a lightweight timestamp beacon alongside video to approximate one-way network latency
  • Observability: Prometheus + Grafana (p50/p95/p99 views)

Tip: run the first pass with host networking to avoid NAT surprises. Harden later.

Bring-up (illustrative):

# Start core + gNB/UE simulators (compose bundle you trust)
docker compose up -d open5gs mongo ueransim-gnb ueransim-ue
Enter fullscreen mode Exit fullscreen mode

What to actually measure (and why)

A. App RTT for control

Send a 50–200-byte UDP packet every 10 ms, echo it back, and record RTT histograms. This reflects your control loop far better than ICMP ping.

B. One-way proxy for video path

Emit 30 JSON “beacons”/sec that include a timestamp; receive them next to your video sink. With NTP-synced clocks, now − beacon_ts gives you an upper-bound estimate of one-way network+queueing latency. You don’t need nanosecond precision—directional insight is the win.

C. Throughput/jitter sanity

Fire a short UDP iperf3 run so you know the path isn’t constrained by an obvious bottleneck while you tune buffers/bitrates.

Minimal commands (enough to get signal)

Baseline throughput/jitter

iperf3 -u -b 20M -c 127.0.0.1 -p 5201 -t 30
Enter fullscreen mode Exit fullscreen mode

Low-latency H.264 test stream
Sender to Receiver on localhost (tune bitrate/jitterbuffer to your case):

# Sender (H.264, tuned for low latency)
gst-launch-1.0 videotestsrc is-live=true ! video/x-raw,framerate=30/1 ! \
  x264enc tune=zerolatency speed-preset=ultrafast key-int-max=30 bitrate=2500 ! \
  rtph264pay pt=96 ! udpsink host=127.0.0.1 port=5600

# Receiver (tight jitter buffer)
gst-launch-1.0 udpsrc port=5600 caps="application/x-rtp,media=video,encoding-name=H264,payload=96" ! \
  rtpjitterbuffer latency=50 drop-on-late=true ! rtph264depay ! avdec_h264 ! fakesink sync=true
Enter fullscreen mode Exit fullscreen mode

Control-loop RTT (concept)
Use a tiny UDP echo server/client (netcat or a 20-line script). Log p50/p95/p99 over 5–10 minutes under the same conditions as your video test.`

The Latency Budget (how to argue trade-offs)

Break your end-to-end into chunks:

L_total = L_cam + L_enc + L_net_up + L_core + L_net_down + L_dec + L_render

You will directly measure:

  • L_app_RTT ≈ 2 × (L_net_up + L_core + L_net_down) via UDP echo
  • L_oneway_proxy ≈ L_net_up + L_core via timestamp beacons

Example goal: 1080p30 at ≤ 200 ms glass-to-glass

  • Encode 40 ms, Decode 40 ms, Render 30 ms to ~110 ms non-network
  • Leaves ~90 ms for the network round-trip
  • Target p95 app RTT ≤ 90 ms and p95 one-way ≤ 45 ms

If you miss the budget:

  • Tighten rtpjitterbuffer latency from 50 to 30 ms (watch for drops)
  • Fix MTU fragmentation (keep payloads < path MTU)
  • Pin CPU for sender/receiver; disable aggressive power saving
  • Use CBR at a realistic bitrate; avoid huge GOPs that add burstiness

This is how you make latency a budget conversation, not a hunch.

Dashboards and alerts (two panels, three rules)

Dashboards

  • Control RTT: p50/p95/p99 over time, plus loss
  • One-way proxy: p95 over time (directional check for congestion)

Alert thresholds (start conservative)

  • Control RTT p95 > 80 ms for 5 min - warn; > 100 ms - critical
  • One-way p95 > 45 ms sustained - warn; > 60 ms - critical
  • Packet loss > 0.5% - warn; > 1% - critical

These catch regressions without paging you for harmless blips.

Reproducibility checklist (the stuff that ruins results)

  • Clock sync: host NTP green; containers inherit host time
  • CPU hygiene: pin cores; keep frequency stable; avoid thermal throttling
  • Warm-up: discard the first 10–20 seconds (encoders & jitter buffers)
  • Change control: one knob at a time (bitrate or jitter buffer or GOP)
  • Background load: note it; don’t compare quiet vs. congested runs
  • Run twice: your “success” isn’t real if you can’t repeat it within ±10%

What “success” looks like before you touch RF

  • Robots/AGVs: sustained p95 control RTT ≤ 80–90 ms, p99 ≤ 120 ms, near-zero loss
  • Cameras (1080p30): one-way p95 ≤ 45–60 ms with jitter buffer ≤ 50 ms, stream clean (no bursty drops)
  • Repeatability: same numbers (±10%) across three runs at different times

If you can’t hit those in emulation, don’t expect miracles in the field. Fix lab hygiene first.

From laptop to field (same harness, new radio)

When you’re happy with your numbers, move the same workloads and thresholds onto a portable 4G/5G kit. Keep the GStreamer settings, the echo cadence, the dashboards—everything. That’s how you tell if RF and mobility are the newvariables, not your pipeline.

Where our team fits: at CloudRAN.AI we use portable, software-defined 4G/5G kits (COTS servers, cloud-managed) so teams can lift this exact harness into venues, factories, or campuses. Same RTT checks. Same Grafana. Same acceptance thresholds. If you’re also monetizing outcomes, Cloudnet.ai’s BSS (Veris) sits on the back end to launch and meter those workloads once they graduate from lab.

A 90-minute runbook

  1. Start Open5GS + UERANSIM (compose bundle you trust).
  2. Add one test UE in the core UI (IMSI/K/OPC).
  3. Sanity-check with a 30-second iperf3 UDP run.
  4. Start UDP echo + the H.264 sender/receiver.
  5. Turn on your dashboards (p50/p95/p99; one-way p95).
  6. Tune jitter buffer and bitrate until you hit the budget.
  7. Save the dashboard; export “golden” JSON and alert thresholds.
  8. Repeat the run. If repeatability is good, you’re ready for field tests.

Bottom line

  • You don’t need radios to know if robots and cameras will behave.
  • Measure control RTT and a one-way proxy under realistic load.
  • Use a latency budget to make trade-offs explicit.
  • Add two panels and three alerts to catch regressions quickly.
  • When you’re green, move the same harness to a portable testbed and validate in the wild.

Top comments (0)