An automated guided vehicle loses its network connection for 200 milliseconds. At walking speed, that's invisible — the vehicle pauses, reconnects, continues. At 3 m/s carrying a 500 kg pallet in a live pick aisle, that 200 ms gap is a safety incident: the vehicle's collision avoidance loop has missed several scan cycles, the fleet controller has lost position telemetry, and the emergency stop logic may or may not have fired in time.
This is not a hypothetical. It is the failure mode that drives the requirement for enforced QoS on AGV control channels. QoS policy for this traffic class is not a performance optimization. It is a safety requirement — and it needs to be treated as such in network design, not as an afterthought tuned during commissioning.
What the AGV control channel actually carries
Understanding the traffic profile is prerequisite to designing the right QoS class. AGV control traffic is not a single flow — it includes at minimum four distinct traffic types, each with different priority requirements:
- Fleet management heartbeat: Position updates from vehicle to fleet controller, typically running at 10–20 Hz. Payload 100–500 bytes per message. Highly latency-sensitive — a missed heartbeat cycle means the controller has stale position data, which forces conservative motion planning (lower speed, larger collision avoidance margins) until the data recovers.
- Route instructions: Path assignments from fleet controller to vehicle, triggered by task assignments and intersection arbitration. Variable payload, 1–10 KB. Required before the vehicle commits to a move; latency impacts fleet throughput capacity, but route instruction delivery is not a real-time safety dependency if the vehicle holds position while waiting.
- Emergency stop commands: E-stop signals from the fleet controller, safety scanners, or zone management system. Very small payload, typically broadcast or multicast. Latency requirement: under 20 ms end-to-end from signal origination to vehicle actuation. This is the most critical traffic on the entire network. It cannot share a best-effort bearer with anything.
- Sensor data backhaul: Lidar point clouds or camera frames for off-vehicle obstacle processing, used in architectures where perception happens at an edge server rather than on the vehicle. High bandwidth, 500 kbps to 5 Mbps per vehicle depending on sensor configuration. Latency requirements depend on architecture — if processing is on-vehicle, this traffic class is non-critical. If processing is off-vehicle in a real-time loop, it needs priority bandwidth but not the same delay budget as e-stop.
These four flows require distinct QoS classes — not a single "AGV traffic" policy. The e-stop bearer and the sensor backhaul bearer have fundamentally different requirements. Conflating them wastes GBR capacity on traffic that doesn't need it.
5G QoS architecture: 5QI classes and GBR bearers
5G NR QoS is defined in 3GPP TS 23.501. The framework is significantly more expressive than anything in 802.11ax — and understanding the core constructs is what separates a well-engineered AGV deployment from one that passes commissioning testing and fails under production load.
5QI (5G QoS Identifier). A numeric identifier that maps to a standardized set of QoS characteristics: resource type (GBR or non-GBR), scheduling priority level, packet delay budget (PDB), and packet error rate (PER). The standardized 5QI table is defined in 3GPP TS 23.501 Table 5.7.4-1; private network deployments can also use operator-assigned 5QI values in the range 128–254 for custom QoS classes not covered by the standard table.
The relevant standardized 5QI values for industrial automation:
- 5QI 82: Discrete Automation — Motion Control, High Reliability. GBR. Default priority level: 19. Packet delay budget: 10 ms. PER: 10⁻⁴. This is the correct class for AGV e-stop commands and collision avoidance loops.
- 5QI 83: Discrete Automation — Motion Control, Lower Reliability variant. GBR. Priority: 22. PDB: 10 ms. PER: 10⁻². Appropriate for position heartbeat traffic where the consequence of a single missed packet is not an immediate safety event.
- 5QI 65: Mission Critical Push-to-Talk base class, adapted in some industrial deployments for SCADA command traffic. GBR. Priority: 7. PDB: 75 ms. Suitable for route instructions and fleet management commands that need reliability but not the 10 ms budget of motion control.
- 5QI 9: General data. Non-GBR. Best effort. This is the correct class for operator tablets, MES terminal traffic, and any traffic that is not safety-classified. If your AGVs are on 5QI 9, you have a configuration problem.
GBR vs. non-GBR bearers. A GBR bearer reserves radio resources for the traffic class. The gNodeB scheduler allocates resource blocks to GBR bearers before any non-GBR traffic is scheduled — the reservation is a hard constraint in the resource block allocation algorithm, not a soft priority. Non-GBR bearers are served from remaining capacity after all GBR bearers have received their guaranteed allocation. AGV e-stop commands must be on a GBR bearer. If they're on a non-GBR bearer — even one marked as high priority — they compete with everything else on the cell under load conditions, and load conditions are exactly when you need them to be guaranteed.
GBR sizing. Set your GBR allocation accurately — not generously. The GBR for a position heartbeat flow at 20 Hz with 500-byte messages is approximately 80 kbps per vehicle. For a 30-vehicle group on a single cell, that's 2.4 Mbps of GBR reservation. If you over-provision GBR at 5 Mbps per vehicle, you're reserving 150 Mbps of cell capacity for heartbeat traffic that only uses 2.4 Mbps — capacity that isn't available for sensor backhaul or route instructions. Set GBR = actual required throughput + 20% headroom, not "large number to be safe."
Network slicing: architecture-level separation vs. QoS-level separation
Network slicing in 5G NR creates logically separate network instances on shared physical infrastructure, each with independent admission control, QoS policies, and optionally separate core network functions (SMF, UPF). Slicing operates at a higher architectural level than 5QI classification — it's the difference between traffic priority enforcement and traffic isolation.
We're not saying slicing is always necessary for AGV deployments — it isn't. For most private cellular deployments with a single-vendor 5G core, 5QI and GBR bearer assignment without full S-NSSAI slicing provides adequate QoS enforcement for AGV control channels. Slicing becomes the right choice when you have multiple distinct populations that need guaranteed isolation from each other: AGV control, SCADA backhaul, corporate IT, and video surveillance all on the same RAN.
If your architecture supports slicing, assign AGV control traffic to a dedicated slice with strict admission control. Set the slice AMBR to match the realistic peak capacity requirement for your AGV fleet and configure admission rejection before the AMBR cap is reached — this prevents non-AGV devices from crowding the slice during a traffic surge. If your architecture does not support slicing, confirm that 5QI assignment is enforced at the PCF level, not just at the gNodeB local configuration. A locally-configured 5QI priority that isn't propagated from the PCF during session establishment can be silently overridden when a UE re-registers after handover.
DSCP marking at the UPF boundary
QoS is enforced at the RAN, but AGV control traffic doesn't terminate at the RAN — it exits the UPF into your campus LAN and then reaches your fleet controller server. The QoS policy needs to carry across that boundary.
DSCP EF (Expedited Forwarding, DSCP value 46, also written as DSCP 101110) is the standard marking for real-time latency-sensitive traffic. Configure your UPF to mark AGV control traffic with DSCP EF on egress. If your LAN switching infrastructure is configured to honor DSCP markings — which it should be in any OT network where latency matters — the QoS enforcement extends from the RAN through to the fleet controller.
If your LAN uses 802.1p CoS rather than DSCP, map DSCP EF to CoS 6 (Internetwork Control equivalent) for queuing purposes. The mapping must be configured at every Layer 2 boundary between the UPF and the fleet server. One switch in the path with a default "trust nothing" CoS policy will silently reclassify the traffic and undo the QoS chain.
Handover continuity: the overlooked failure mode
GBR bearers provide guaranteed bit rate within a cell. AGVs don't stay in one cell — they move through the facility, triggering handovers as they cross cell boundaries. The handover event itself has a latency gap that can violate your AGV control channel's PDB even when the GBR policy is perfectly configured.
In 5G NR, intra-gNodeB handover (between two cells on the same gNodeB) typically completes in 10–20 ms. Inter-gNodeB handover (between cells on different gNodeBs, coordinated over Xn interface) can take 30–50 ms depending on backhaul latency. For a 5QI 82 bearer with a 10 ms PDB, an inter-gNodeB handover event inherently violates the PDB budget during the transition — regardless of how well the QoS policy is configured.
Practical mitigations:
- Target handover trigger at received power level A3 offset such that handover initiates when the UE still has ≥ 10 dB SINR on both source and target cells — not when it's already at the coverage edge with 3 dB on the source.
- Enable Contention-Free Random Access (CFRA) for handover target cells if your RAN vendor supports it. CFRA pre-allocates random access resources for the handover UE, eliminating the random access contention delay during the transition and reducing handover completion time by 5–10 ms.
- For AGV travel corridors that cross gNodeB boundaries, consider Dual Connectivity (NR-DC) — the UE maintains active connections to both the source and target cell simultaneously during the handover zone, eliminating the radio path gap entirely. NR-DC requires gNodeB support and X2/Xn interface configuration, but the complexity is justified for corridors where inter-gNodeB crossings happen multiple times per shift.
Validating QoS enforcement before production go-live
NMS UI confirmation that a QoS policy is configured is not the same as confirming it is enforced. Before declaring your AGV network ready for production, run a deliberate adversarial load test: generate cell saturation using iperf3 UDP streams from multiple non-AGV test UEs (target 80–90% of cell capacity) and simultaneously measure the round-trip latency of a UDP echo stream on the AGV bearer. If the echo latency increases above the 5QI 82 PDB of 10 ms under load, the GBR enforcement is broken — either a misconfigured bearer parameter, an incorrect 5QI mapping in the vendor's QoS table, or a PCF policy that isn't propagating correctly to the gNodeB.
Also capture the gNodeB scheduler trace during the test. The trace should show the AGV GBR bearer receiving its resource block allocation in every TTI regardless of background traffic load. If the GBR allocation shrinks under congestion, you have a scheduler configuration issue rather than a policy issue — different root cause, different fix path.
Run this before the AGV vendor's integration team shows up for site acceptance testing. A QoS misconfiguration discovered during acceptance is a configuration change. The same misconfiguration discovered after fleet go-live is a production incident with a maintenance window, a freeze request, and an explanation to operations management about why the network passed acceptance and still stopped vehicles.