> For the complete documentation index, see [llms.txt](https://docs.gxc.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.gxc.io/usecases-workflows/manufacturing/agv-and-amr-fleet-control.md).
# AGV and AMR fleet control
## Overview
Automated guided vehicles and autonomous mobile robots are the workflow that exposes the difference between "wireless" and "deterministic wireless". Wi-Fi carries AGV traffic well enough on a quiet floor, but every roaming event hands the vehicle from one access point to another, and every handover is a gap. A vehicle that loses its supervisory link stops — correctly and safely, but it stops. On a floor with a hundred vehicles, an unplanned stop is a cascading blockage, and the cost of the network is measured in throughput lost to conservative safety timeouts.
Private 5G addresses this in three ways that matter more than raw bandwidth. Delay-critical GBR bearers give the control link a 10 ms packet delay budget with a guaranteed rate, so the supervisory loop is bounded rather than best-effort. The shared-cell architecture presents the whole floor as one logical cell, so a vehicle crossing from one radio's coverage to another's does not hand over — there is no cell boundary to cross and no gap to absorb. And the fleet manager runs on the Onyx Edge appliance beside the core, so the round trip from vehicle to decision and back stays inside the building.
***
## How It Works
### The control loop
### What each component does
| Component | Role in this workflow |
| ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Vehicle navigation and drive control** | Onboard autonomy. Executes route segments and reports position, state, and battery |
| **5G module** | Vehicle-mounted, rated for floor vibration and temperature, antennas clear of the chassis and above the load |
| **Onyx RU** | The radio. Many low-power RUs beat one high site for coverage at vehicle antenna height, typically 300–800 mm |
| **FHM** | Presents every RU as **one logical cell** across the whole floor. This is the component that eliminates handover, and therefore eliminates the most common cause of unplanned stops |
| **Onyx Edge — 5G Core** | Enforces 5QI 82/83, delay-critical GBR with a 10 ms packet delay budget, on a bearer separate from everything else the vehicle carries |
| **Fleet manager** | Hosted on the Onyx Edge. Route allocation, intersection reservation, deadlock avoidance, charge scheduling. Commonly interfaces to vehicles over **VDA 5050** |
| **Onboard safety controller** | Safety-rated scanners and bumpers wired to the drive. **Independent of the network** |
| **WMS / MES** | Over the plant network, on a separate and deliberately non-latency-critical QoS class |
| **Unified radio layer under one DU** | Eliminates inter-cell interference in a dense RU deployment — normally the penalty for adding coverage |
| **Onyx Portal** | Per-vehicle latency, throughput, RSRP, SINR, BLER, and link-loss events, correlated to fleet-manager records |
| **Mesh Node** | Wireless backhaul to RUs in areas where conduit cannot be run |
### The control loop, hop by hop
| # | From → To | Interface | What happens |
| - | -------------------------- | --------------------- | ----------------------------------------------------------------------------------------------- |
| 1 | Navigation → 5G module | Internal | Position, state, and battery packaged for report |
| 2 | 5G module → Onyx RU | **5G NR Uu**, uplink | Small packets on the 5QI 82/83 delay-critical GBR bearer |
| 3 | Onyx RU → FHM | **eCPRI**, O-RAN 7.2x | Aggregated into one logical cell spanning the floor |
| 4 | FHM → Onyx Edge DU | Aggregated fronthaul | **No handover decision exists.** The vehicle has crossed radio coverage but not a cell boundary |
| 5 | DU → CU → UPF | F1 / N3, internal | Delay-critical scheduling; the QoS flow is policed against a 10 ms budget |
| 6 | UPF → Fleet manager | **N6 local breakout** | Report reaches the fleet manager on the same appliance |
| 7 | *Inside the fleet manager* | VDA 5050 or ROS 2 | Allocates the next route segment, reserves the intersections it needs, checks for deadlock |
| 8 | Fleet manager → Vehicle | Reverse of 6→2 | Route grant on the same bearer |
| 9 | Vehicle | Internal | Acknowledges and executes |
**Running continuously and in parallel:** onboard safety scanners → safety controller → drive stop. This path never touches the network and functions with the network fully down.
### Where the latency goes
| Stage | Typical contribution |
| ---------------------------------- | ---------------------------------------- |
| Vehicle sense and report | 2–5 ms |
| 5G uplink | 2–4 ms |
| Onyx Edge + fleet manager decision | 3–10 ms |
| 5G downlink | 2–4 ms |
| Vehicle actuation | 2–5 ms |
| **Total control loop** | **\~11–28 ms**, inside a 20–100 ms cycle |
The number that matters is not the mean — it is the **tail**. The relevant question is how often the gap exceeds the vehicle's link-loss timeout. Measure the 99.9th percentile and alarm on it.
### Why safety is not on this diagram's critical path
Functional safety does not depend on the radio, and no network design should imply otherwise. Each vehicle carries safety-rated onboard sensing that stops it independently of any network state, per the applicable machinery safety standards.
Where safety-related data *does* traverse the network, it uses a **black-channel** protocol such as PROFIsafe or FSoE. That protocol carries its own sequence numbering, CRC, and watchdog end to end, and treats the 5G bearer as untrusted transport — it detects loss, delay, and corruption itself and forces the safe state. Design the network to meet the watchdog interval with margin, and verify the vehicle reaches its safe state when that watchdog expires. Never design a system where a network guarantee is load-bearing for a safety function.
***
## Network Requirements
| Parameter | Target |
| -------------------------------------- | -------------------------------------------------------------------- |
| Control traffic per vehicle | 0.5–2 Mbps, symmetric, small packets |
| Optional onboard video per vehicle | 4–8 Mbps uplink |
| Aggregate, 50-vehicle fleet with video | \~150 Mbps |
| One-way network latency, control | < 10 ms |
| Jitter | < 3 ms |
| Packet error rate | 10-4 |
| Control loop cycle time | 20–100 ms depending on vehicle speed and stopping distance |
| Link-loss tolerance before safe stop | Vehicle-defined, typically 100–500 ms |
| Availability | 99.999% |
| Handover interruption | Zero — shared cell, no inter-cell handover on the floor |
| Control QoS | **5QI 82 / 83** — delay-critical GBR, 10 ms PDB, 10-4 PER |
| Onboard video QoS | **5QI 67** — GBR, mission-critical video, 100 ms PDB |
| TDD pattern | `DDSUU`, latency-optimised |
| Bands | n77, n78, n48 (CBRS), n40 |
## Deploying It
{% stepper %}
{% step %}
### Map routes, then design coverage to them
AGV coverage requirements are linear — aisles, cross-docks, charging bays — not areal. Survey at **vehicle antenna height** on a **loaded floor**; an empty warehouse and a full one are different RF environments, and a chest-height survey in an empty building will not reveal what racking does at 500 mm.
{% endstep %}
{% step %}
### Configure the shared cell
Every floor RU as one logical cell under one DU via the FHM. This is the single most important configuration choice in the workflow.
{% endstep %}
{% step %}
### Set QoS and TDD
Vehicle Control group on 5QI 82/83. A latency-optimised `DDSUU` pattern; shorter slot periodicity reduces scheduling latency at some capacity cost. Where vehicles carry cameras, provision a **second, separate** bearer on 5QI 67 — never share the control loop's bearer with video.
{% endstep %}
{% step %}
### Onboard vehicles
5G module or industrial CPE with external antennas. Provision in Onyx Portal; record vehicle ID to IMSI in the fleet management system. Configure the VDA 5050 or ROS 2 interface. Confirm each vehicle's link-loss behaviour and timeout — that is the behaviour the network design exists to avoid triggering.
{% endstep %}
{% step %}
### Deploy the fleet manager
Deploy the fleet manager on the Onyx Edge or on the same local segment through local breakout. Integrate WMS/MES over the plant network on its own QoS class.
{% endstep %}
{% step %}
### Verify the safety layer independently
Force watchdog expiry and confirm the safe state. Confirm onboard sensing operates with the network fully down.
{% endstep %}
{% step %}
### Monitor
Achieved latency and jitter per vehicle against the 10 ms budget; link-loss events correlated to floor position — a recurring drop at one location is a coverage hole, not a vehicle fault; BLER as the early indicator.
{% endstep %}
{% step %}
### Build re-survey into change management
Racking moves, mezzanines go in, a line is commissioned. Each is an RF change. Re-survey affected areas and re-validate routes rather than discovering the change through vehicle stops.
{% endstep %}
{% endstepper %}
## Devices & Ecosystem
* **5G modules and industrial CPE** — vehicle-mounted, rated for the vibration and temperature range of the floor, with external antennas.
* **Fleet management systems** — hosted on Onyx Edge; **VDA 5050** is the common interoperability interface between fleet manager and vehicles from multiple vendors.
* **AMR autonomy stacks** — ROS 2–based vehicles with onboard SLAM, using the network for supervisory and coordination traffic rather than closed-loop control.
* **Safety controllers** — onboard safety-rated scanners and bumpers; PROFIsafe or FSoE where safety data crosses the network.
* **WMS / MES integration** — over the plant network on a separate, non-latency-critical QoS class.
* **Charging infrastructure** — opportunity or automatic charging, scheduled by the fleet manager.
## Design Considerations
**Shared cell is not an optimisation here; it is the requirement.** Every other design decision on this page can be traded. Handover-free mobility cannot. A conventional multi-cell deployment reintroduces exactly the failure mode this workflow exists to eliminate.
**Survey at vehicle height, on a loaded floor.** This is the most common cause of a design that validates and then fails in production. The RF environment 500 mm above a concrete floor between full racking bays is not the environment a survey device at chest height in an empty building measures.
**Separate the control bearer from everything else the vehicle carries.** A vehicle with a camera, a tablet in a dock, and a control link should have three distinct QoS treatments. Sharing them means a video burst can delay a control message.
**Design to the vehicle's link-loss timeout, not to an average.** The relevant question is not "what is mean latency" but "how often does the gap exceed the vehicle's tolerance". Measure the tail, not the mean, and set alarms on the tail.
**Safety is onboard.** The network carries supervisory control. Onboard sensing stops the vehicle. Where safety data does cross the network, a black-channel protocol carries its own integrity and timing checks and forces the safe state on its own. Do not design a system where a network guarantee is load-bearing for a safety function.
**Layout changes are RF changes.** Racking, mezzanines, and new lines all change coverage. Build re-survey into the plant's change-management process rather than discovering the change through vehicle stops.
## Validation Checklist
* [ ] Vehicle routes mapped, and coverage designed to routes rather than to floor area
* [ ] Survey performed at vehicle antenna height, on a loaded floor
* [ ] Shared cell configured across all floor RUs; verified as a single logical cell
* [ ] Zero handover events observed on a full-floor test run
* [ ] Latency-optimised TDD pattern configured and matched across the band
* [ ] Control traffic on 5QI 82/83, on a bearer separate from video and IT traffic
* [ ] Latency tail measured under peak fleet load — 99.9th percentile inside the vehicle's timeout, not just the mean
* [ ] Link-loss behaviour and recovery confirmed for each vehicle type
* [ ] Safety layer verified independently of the network: forced watchdog expiry produces the safe state
* [ ] Onboard safety sensing confirmed to operate with the network fully down
* [ ] Full-fleet peak test — every vehicle active, video streaming, WMS integration live
* [ ] Vehicle ID to IMSI mapping recorded in the fleet management system
* [ ] Link-loss alarms correlated to floor position and routed to plant maintenance
* [ ] Re-survey trigger added to the plant change-management process
***
## Related reading
* [Visual Daily Inspection on 5G](broken://pages/01980a92265ec06fedea0611070b1b4956e227fa)
* [Asset & Forklift Tracking on 5G](broken://pages/cc14fd9d499d83b77a575ff9dc43f89b1429d34a)
* [Network Requirements at a Glance](broken://pages/d8ba02440bfd0f056f057fd9b67a87d38f1d8507)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.gxc.io/usecases-workflows/manufacturing/agv-and-amr-fleet-control.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.