AMR Wi-Fi vs. Private 5G vs. Mesh: 3 Warehouse Robot Networks Compared for 2026

Q: Is private 5G worth it for AMRs?

For most indoor fleets, not as a first move. Robots stopping during roaming handoffs is usually fixable with a measured site survey and a Wi-Fi redesign, at a fraction of the cost of a private core, new radios, and a 5G module per robot. Private 5G becomes worth it for large or mixed indoor/outdoor sites, sites whose rack geometry changes constantly, or organizations that want SIM-based device authentication and a dedicated core.

Q: Why do AMRs stop when they roam between access points?

The robot's radio decides when to switch access points, and while it re-associates and re-authenticates the session with the fleet manager can lapse. Most fleet managers treat a lost controller connection as a condition requiring the vehicle to stop and hold. This is a vendor-designed fail-safe behaviour, not the safety-rated stop required by AMR safety standards. ANSI/RIA R15.08-1 specifies the robot's emergency-stop and protective-stop functions and presence-sensing devices as requirements on the machine itself, and ISO 3691-4 specifies the truck's safety functions in its own safety-related control system.

Q: How many access points does an AMR fleet need?

There is no valid per-robot or per-square-metre number. AP count is an output of a measured design based on coverage geometry, rack layout, interference environment, and the robots' roaming behaviour. Adding access points without a design can make roaming worse by creating more marginal roam candidates and more co-channel interference.

Q: Will Wi-Fi 7 fix AMR roaming problems?

Potentially. Multi-Link Operation lets a client hold associations across multiple links rather than making a hard break-before-make switch, which targets the roaming gap that stops robots. The caveats are that 802.11be makes support for both MLO modes mandatory for access-point multi-link devices but optional for client devices, so the robot's radio decides which mode you get; eMLSR is the mode to plan against, as vendors disagree on how widely full simultaneous transmit-and-receive is shipping and it is scarcest on the client side; and most AMRs in service today have older radios.

Diagram comparing three warehouse robot network options — Wi-Fi, where the robot itself decides when to roam and can lose the link at the gap between access points; private 5G, where a central core controls the handover; and industrial mesh, where interlinked nodes re-route the path — above a band showing that losing the fleet-manager link is what triggers a robot's fail-safe stop.

For most indoor AMR fleets, the honest 2026 answer is that you probably need a re-surveyed and retuned Wi-Fi network, not a private 5G rebuild — the network you already own usually fails for reasons a new radio technology doesn't automatically fix. Private 5G earns its cost in three specific situations: very large or mixed indoor/outdoor sites, sites where coverage has to survive constantly changing rack and inventory geometry, and organizations that want SIM-based device authentication and a dedicated core instead of robots living on a shared corporate SSID. Industrial kinetic mesh is the third option almost nobody mentions, and it exists because yards, ports, and mixed indoor/outdoor logistics sites break both of the other two. The decision is really retune vs. rebuild vs. replace, and the first of those three is the one every vendor on both sides has an incentive not to price for you.

By The Whitepaper Skeptic — led AMR vendor evaluation and OT network architecture reviews

Quick Facts

Question	Answer
What fixes most indoor AMR connectivity problems?	A validated site survey and Wi-Fi retune measured from robot antenna height — not a new radio technology
When does private 5G actually earn its cost?	Large or mixed indoor/outdoor sites, constantly changing rack geometry, or when SIM-based device authentication and a dedicated core solve a security/ownership problem
Where does industrial mesh fit?	Yards, ports, container terminals, and sites where vehicles move between indoor and outdoor coverage
Why does a robot stop when nothing appears to be "down"?	Loss of the fleet-manager connection triggers a vendor-designed fail-safe stop — this is separate from the safety-rated stop, which ISO 3691-4 and ANSI/A3 R15.08 place on the robot itself
What should you buy before any network hardware?	Measurement: survey and validation tooling that records what the robot's radio sees while it drives its actual routes

Why Robots Stop When the Network Never Actually Went Down

The failure that drives this entire buying decision is not an outage. It's a handoff.

An AMR maintains a continuous session with its fleet manager. In a VDA 5050 deployment, that link is an MQTT session, and the specification defines a dedicated connection topic backed by MQTT's Last Will and Testament mechanism — the robot registers a last will on connect, and the broker publishes it with connectionState set to CONNECTION_BROKEN when the session drops unexpectedly rather than through a graceful OFFLINE disconnect. That mechanism exists precisely because the fleet manager has to distinguish "robot is idle" from "robot is unreachable," and a robot that has become unreachable cannot be safely dispatched into a shared aisle.

What happens next is a vendor design decision, not a standards requirement: most fleet managers and robot controllers treat a lost controller connection as a condition requiring the vehicle to stop and hold. That is a fail-safe stop driven by application-layer logic. It is not the safety-rated stop governed by ISO 3691-4 or the ANSI/A3 R15.08 series. Those standards put the stop functions and the means of detecting people on the vehicle. ANSI/RIA R15.08-1 is written for the manufacturer of the industrial mobile robot and specifies the robot's own emergency-stop and protective-stop functions along with its presence-sensing devices — contact bumpers and non-contact safety scanners — as built-in features of the machine; ISO 3691-4:2023 likewise specifies the safety requirements and verification means for the truck itself, with those functions realized in its safety-related parts of the control system and verified to performance levels under ISO 13849-1. A robot that loses its fleet-manager link therefore loses its work, not its stop. Conflating the two is the single most common error in this topic area, and it matters commercially: if you believe network dropouts create a safety hazard, you will over-buy radio infrastructure; once you understand they create a throughput problem, you can price the fix rationally. We covered the safety-side standards separately in our AMR safety standards comparison — nothing in this article changes what those standards require.

The roaming mechanics behind those dropouts are worth stating plainly, because they explain why "more access points" is so often the wrong answer:

The client decides when to roam, not the AP. The robot's radio chooses when to leave one access point for another, using its own vendor-specific thresholds. Your controller can nudge that decision with 802.11k neighbor reports and 802.11v BSS transition management, and shorten the re-authentication that follows with 802.11r fast BSS transition — but the decision itself lives in a radio module you didn't design and often can't tune.
Warehouse Wi-Fi was engineered for a different client. Handheld scanners tolerate a dropout of a second or two invisibly; the operator never notices. A moving robot in the middle of a dispatch cycle does not have that tolerance, and 7SIGNAL lists roaming failure — robots dropping off the network as they move between APs — among the common problems in AGV and AMR wireless deployments, alongside AP placement and handoff thresholds as the things it helps fine-tune.
Adding APs can make roaming worse. More overlapping cells give the client more roam candidates and more opportunities to make a bad decision, plus more co-channel interference. This is why the fix is a survey-driven redesign, not a hardware count.

The Three Options, Side by Side

Nearly every article on this question is published by a vendor selling one of the three. Here is the neutral version.

Dimension	Enterprise Wi-Fi (6E / 7)	Private 5G (CBRS or local licensed)	Industrial kinetic mesh
Spectrum	Unlicensed 2.4 / 5 / 6 GHz — no license, but no protection from neighbors either	Shared or locally licensed band (US CBRS 3.55–3.7 GHz; Germany 3.7–3.8 GHz local licenses via BNetzA)	Typically unlicensed bands, multi-radio
Mobility model	Client-led roaming between APs; handoff quality depends on the robot's own radio	Network-controlled handover, designed for mobility from the start	Every node is a router; peer-to-peer paths re-form as vehicles move
Device authentication	WPA2/WPA3-Enterprise with 802.1X on a shared SSID, or a dedicated robot SSID/VLAN	SIM/eSIM-based subscriber authentication against a dedicated core	Vendor-specific radio/network credentials
Per-robot hardware	Already present on essentially every AMR shipping today	5G module or gateway added per robot — an integration item, not a checkbox	Mesh radio node added per vehicle
Who typically owns it	Corporate IT	Contested: IT owns the network stack, operations owns the outcome	Usually operations / site engineering
Best-fit site	Indoor, structured, stable rack geometry	Large campuses, mixed indoor/outdoor, dense metal, high change rate	Yards, ports, terminals, mining, indoor↔outdoor transitions
Realistic worst case	Roaming gaps and interference you don't control	Long procurement and integration cycle for a problem a retune may have solved	Vendor lock-in to a proprietary mesh ecosystem
Failure mode when it degrades	Sudden — robot stops at a specific location, repeatably	Graceful — throughput drops before sessions break	Path re-routing masks degradation until capacity runs out

Two things changed in 2026 that make this a genuinely open comparison rather than a foregone conclusion.

On the cellular side, the framing has shifted from pilots to production. Fortress Solutions' 2026 outlook expects enterprises to move pilot evaluations onto production-grade infrastructure this year, and market coverage of Germany's local-licence ecosystem describes it as past the pilot phase — with the caveat, in that same coverage, that converting technical capability into repeatable production deployments is still the open question. Germany is the reference market here precisely because BNetzA made local spectrum directly available to industrial sites rather than only to carriers.

On the Wi-Fi side, Wi-Fi 7's Multi-Link Operation attacks the exact weakness that made Wi-Fi unsuitable for robots: instead of a hard break-before-make handoff on a single link, a client can maintain association across multiple links and bands. Which MLO mode you actually get, though, is decided at the client — the same place the roaming decision lives. Cisco's dissection of 802.11be makes the structural point: support for both eMLSR (enhanced multi-link single radio) and STR (simultaneous transmit and receive) is mandatory for access-point multi-link devices but optional for non-AP devices, so the robot's radio sets the ceiling, not your infrastructure.

On what is actually in the field the vendors disagree, and it is worth knowing that before you read a datasheet: Purple's 2026 guide states that true STR is not yet available in shipping enterprise equipment and treats eMLSR as the deployable mode; Cisco reports STR working in its own lab with a Qualcomm FastConnect 7800 client and says most vendors now incorporate it; independent commentary in mid-2026 splits the difference, describing eMLSR as what virtually every phone, laptop and Wi-Fi 7 adapter ships with while STR appears first in high-end APs and in a small number of specialist client radios. The practical reading for a fleet owner is that eMLSR is the mode to plan against and STR is something to ask your robot vendor about by part number rather than assume. Independent work matters here more than vendor claims: an arXiv testbed paper on MLO in industrial Wi-Fi settings is one of the few peer-review-grade evaluations available, and it is a better basis for your expectations than either side's marketing.

The practical consequence: "just go private 5G" was defensible advice in 2023. In 2026 it is a claim that has to be argued against a Wi-Fi baseline that moved.

Symptom-to-Cause: What Your Robots Are Actually Telling You

Warehouse operations teams don't search for "MLO." They search for the symptom. This table maps what you observe to what's likely causing it and to which of the three paths actually resolves it.

Observed symptom	Most likely cause	Does a Wi-Fi retune fix it?	When to escalate to 5G or mesh
Robot stops at the same spot every time	Coverage hole or a roaming boundary at that location; client roams late and loses the controller session	Yes — this is the classic survey-and-retune case	Only if the location is physically un-coverable (outdoor gap, freezer wall, tall metal)
Fine with 5 robots, collapses at 40	Airtime contention and co-channel interference, not coverage	Usually — channel plan, cell sizing, band steering, and data-rate policy	If contention persists after redesign, licensed spectrum's interference control becomes the argument
Works when racks are empty, fails when full	RF environment changes with inventory; a predictive survey done on an empty floor doesn't describe the live site	Yes, but only with a measured survey under representative load	If the geometry changes constantly (seasonal peaks, reslotting), the case for 5G's propagation and network-controlled handover strengthens
Drops at the dock door or yard boundary	Indoor design ends where the building does	No — this is a coverage-model problem, not a tuning problem	This is mesh's home territory, and a common private-5G justification
Intermittent, no location pattern, worse at shift change	Interference from non-Wi-Fi sources or neighbouring networks in unlicensed spectrum	Partially — spectrum analysis first, then channel planning	Persistent uncontrollable interference is the strongest technical case for licensed spectrum
Fleet manager shows robots "online" but commands lag	Backhaul, broker, or fleet-manager-side bottleneck — not the radio at all	Irrelevant — the radio isn't the problem	Neither; fix the software/backhaul layer first

That last row is not filler. In the AMR work we did at The Won, the first assumption whenever something looked like a "network problem" was almost always wrong — the symptom pointed at the radio because that's the layer everybody can see, while the actual constraint sat in the integration between the fleet manager and the upstream system. We wrote about that stack in detail in our AMR–WMS/WES integration explainer, and it's worth ruling out before anyone signs a spectrum contract.

Retune vs. Rebuild vs. Replace — and What Each One Actually Costs You

No 2026 source we found publishes credible cross-vendor pricing for per-robot 5G modules, private core capex, or managed-service opex — and the qualitative reporting that does exist points somewhere else entirely: market coverage of Germany's local-licence ecosystem reports that the work of tying a private network into the OT systems around it can end up costing more than the radios and core it connects. So rather than invent dollar figures, here is the honest structure: the categories of spend each path commits you to. Fill in your own quotes; the point is that the columns are not the same shape.

Cost category	Retune existing Wi-Fi	Rebuild on private 5G	Replace with industrial mesh
Spectrum / licensing	None	Licence or shared-access fees, jurisdiction-dependent	None (unlicensed)
Core / controller	Already owned	New dedicated core (on-prem or managed)	Vendor mesh management stack
Infrastructure radios	Possible AP additions/relocations	New radio units and backhaul	New mesh nodes
Per-robot hardware	None — existing Wi-Fi radios	5G module/gateway per robot, plus integration and validation per robot type	Mesh radio per vehicle
Design & validation	Measured site survey; the core spend	Survey plus RF design plus core design	Survey plus mesh path planning
Ongoing	Continuous monitoring/sensing subscription (optional but the highest-value line item)	Managed-service or in-house cellular skills, recurring data capacity	Vendor support contract
Organizational	Low — same team, same tools	High — new skill set, new ownership boundary, new vendor relationships	Medium — usually operations-owned

The line item most teams under-fund is design and validation, and it's the one that determines whether any of the three works. A survey done from a laptop at chest height on an empty floor does not describe what a robot's radio experiences at deck height, at speed, between full racks. One UK integrator, Performance Networks, puts the routine discrepancy between a predictive survey's numbers and what a robot's own radio records on the floor at somewhere between 12 and 20 dBm — that is a single-vendor figure, not an industry finding, so treat it as an illustration of the direction of the error rather than a number to design against: predictive surveys systematically flatter the network.

We are deliberately not quoting minimum RSSI, SNR floors, cell-overlap percentages, or target handoff times in this article. Those thresholds vary by vendor and by fleet-manager design, and the useful ones come from a named design guide that states its own assumptions — Cisco's Industrial Automation wireless design guide and its factory AGV/AMR reference design are one such published example, though note that the latter is built around Cisco's own Ultra-Reliable Wireless Backhaul rather than generic enterprise Wi-Fi. Any consultant who quotes you a universal dBm number without naming the guide it comes from is quoting marketing.

The Part Nobody Frames Correctly: This Is an IT/OT Boundary Decision

The technical comparison above is the easy half. The half that actually blocks deployments is organizational, and it comes down to one question: who owns the wireless layer the robots run on?

In practice the robot fleet is an operations asset, the wireless network is an IT asset, and the fleet manager sits in between — increasingly as a cloud-connected service. That means the moment you deploy AMRs, you have created an OT asset whose availability depends on a network that the OT team does not administer, monitor, or change-control. When something stops, the two teams have different dashboards, different definitions of "the network is fine," and different change windows.

I have made this mistake myself. On the AMR vendor evaluation I led at The Won, the wireless network sat in the assumptions section of the requirement set — "the site provides coverage" — instead of in the scored criteria. Navigation, safety, and fleet software each got a weighted score and a named reviewer; the radio layer got a sentence and no owner, so no supplier was ever asked to defend it and no internal team was ever assigned it. The comparison that came out of that process was clean and, on the one dimension that determines whether any of the rest functions, empty. The OT network architecture reviews I worked on later hit the same gap from the security side — the robot wireless layer kept falling outside whichever zone diagram was on the table, because it belonged to neither the plant network nor the corporate one. My correction is narrow and cheap: make "who administers this network and who gets paged when it degrades" a scored line item with a named owner on both sides, at the same weight as navigation accuracy. It costs one row in a spreadsheet, and it is the row that would have changed my own evaluation.

Private 5G quietly changes the security model as well, and this is rarely mentioned in the RF-focused comparisons:

Device authentication moves from WPA2/802.1X on a shared SSID to SIM/eSIM-based subscriber identity against a dedicated core. Credentials live in hardware, and enrollment becomes a provisioning process rather than a certificate or PSK distribution problem.
The core is yours. Robot traffic doesn't traverse the corporate SSID at all, which is a cleaner segmentation story than a robot VLAN riding on the same infrastructure as guest and office traffic.
But you've added an OT asset class. A private core, its management plane, and the SIM lifecycle all become things that need patching, monitoring, and access control — inside the same zone-and-conduit model as everything else on the plant floor.

That last point is where this decision connects to the rest of OT security rather than sitting off to the side. If you're designing zones and conduits under IEC 62443, the wireless layer and the fleet controller belong in that model explicitly — see our IEC 62443 zones and conduits walkthrough for how to draw those boundaries, and our OT cybersecurity primer for why the IT security model doesn't transfer directly. The robots themselves are also a documented attack surface: we catalogued the disclosed vulnerability history in AMR cybersecurity, and the network decision either widens or narrows that exposure.

There's one more organizational trap. Your fleet-management software's assumptions about connectivity are a procurement variable, not a fixed constraint — some platforms degrade gracefully on a lost link, others stop hard. That belongs in the evaluation criteria alongside the interoperability questions we listed in our fleet management software comparison and the multi-vendor messaging layer covered in our VDA 5050 explainer.

What the 5G Latency Numbers Do and Don't Mean

Private 5G pitches lean on URLLC figures: user-plane latency around 1 ms and reliability up to 99.9999%. Those are 3GPP specification targets as summarized by 5G-ACIA, defined for specific packet sizes and radio conditions. They are not measurements of a working warehouse, and no AMR fleet-manager protocol in common use needs 1 ms anyway — MQTT-based fleet messaging operates in a completely different order of magnitude.

Releases 16 through 18 established the URLLC and industrial-IoT feature baseline that these targets come from. If a vendor cites a specific newer release as the reason to buy now, ask what feature in it changes your deployment, and verify the release's status directly with 3GPP rather than accepting the number in a slide.

The useful takeaway is inverted from how it's usually sold: the argument for private 5G in a warehouse is not latency. It's deterministic mobility, interference control in protected spectrum, and a device-identity model that solves an ownership problem. If a proposal leads with 1 ms latency, it's selling you a spec sheet rather than diagnosing your site.

Spectrum: What You Are Actually Allowed to Use

Feasibility is jurisdictional before it's technical.

United States — CBRS makes shared spectrum at 3.55–3.7 GHz available without buying a carrier licence, which is why "CBRS private network warehouse" is a distinct search from "private 5G." Access tiers and coordination rules are administered under the FCC's framework.
Germany — BNetzA issues local licences in the 3.7–3.8 GHz range directly to industrial sites, which is why German manufacturing is the reference market for private 5G maturity. The parameters are worth knowing before anyone quotes them at you: spectrum is assigned in 10 MHz blocks from a minimum of 10 MHz up to a maximum of 100 MHz, operation is TDD only, and assignments run for a term of years — 10 is the worked example in BNetzA's own fee formula — with all local assignments in this band ending no later than the end of 2040. If you need a current count of assignments issued, pull it from BNetzA's published list of assignment holders rather than from a market report.
Everywhere else — check before you design. 5G-ACIA maintains country-by-country guidance, and the availability of local licensing is frequently the deciding factor in whether private 5G is even on the table for a given site.

What to Measure Before You Approve the Spend

If you take one thing from this article, take this checklist. Every item is cheaper than any of the three network paths, and the results usually eliminate at least one option outright.

Survey from the robot's perspective. Measure at the robot's actual antenna height, along its actual routes, at operating speed — not from a cart at chest height.
Survey under representative load. Empty racks are a different RF environment from full ones. If your peak looks different from your baseline, measure both.
Capture roaming events, not just coverage. A heatmap showing good signal everywhere can coexist with robots that stop at every cell boundary. You need the handoff timeline, not just RSSI.
Correlate stops with locations. Pull the fleet manager's stop log and plot it on the floor map. Repeatable stops at the same coordinates are an RF story; scattered stops are usually not.
Run a spectrum analysis, not just a Wi-Fi scan. Non-Wi-Fi interference is invisible to Wi-Fi-only tools and is a leading cause of "unexplained" degradation in unlicensed bands.
Ask the robot vendor what their radio does. Roaming thresholds, supported fast-roaming standards (802.11k/v/r), and the fleet manager's link-loss behaviour are all vendor-specific answers you're entitled to before purchase.
Establish continuous monitoring before you change anything. A one-time survey is a snapshot; robots fail on a schedule that snapshots miss. Sensor-based continuous monitoring gives you a before/after you can actually defend.
Write down who owns the answer. If IT and operations don't agree in advance on who administers the robot network and who gets paged when it degrades, no radio technology will fix that.

Do all eight, and the "which network" question usually answers itself — often in favour of the option nobody was selling you.

FAQ

Q: Is private 5G worth it for AMRs?

A: For most indoor fleets, not as a first move. The common failure — robots stopping during roaming handoffs — is usually fixable with a measured site survey and a Wi-Fi redesign, at a fraction of the cost of a private core, new radios, and a 5G module per robot. Private 5G becomes genuinely worth it when the site is large or mixed indoor/outdoor, when rack and inventory geometry changes constantly enough that a static Wi-Fi design keeps drifting out of tune, or when you specifically want SIM-based device authentication and a dedicated core instead of robots on shared corporate wireless. Diagnose first, then decide.

Q: Why do AMRs stop when they roam between access points?

A: Because the robot's radio, not the access point, decides when to switch — and while it re-associates and re-authenticates, the session with the fleet manager can lapse. Most fleet managers treat a lost controller connection as a condition requiring the vehicle to stop and hold, so a handoff that a handheld scanner would absorb invisibly becomes a visible stop. Note that this is a vendor-designed fail-safe behaviour, not the safety-rated stop required by AMR safety standards. ANSI/RIA R15.08-1 specifies the robot's emergency-stop and protective-stop functions and its presence-sensing devices as requirements on the machine itself, and ISO 3691-4 specifies the truck's safety functions in its own safety-related control system. Losing the fleet-manager link costs the robot its task, not its stop.

Q: How many access points does an AMR fleet need?

A: There is no valid per-robot or per-square-metre number, and anyone quoting one without a survey of your site is guessing. AP count is an output of a measured design — coverage geometry, rack layout, interference environment, and the robots' own roaming behaviour — not an input. Adding APs without a design can make roaming worse by creating more marginal roam candidates and more co-channel interference.

Q: What is CBRS and do I need it for a warehouse private network?

A: CBRS is the US shared-spectrum framework at 3.55–3.7 GHz that lets an enterprise run a private cellular network without buying a carrier licence. You need it if you're deploying private LTE/5G in the US; it's the mechanism that makes private cellular legally accessible there. Other jurisdictions have their own routes — Germany, for example, issues local industrial licences at 3.7–3.8 GHz through BNetzA. What CBRS doesn't do is answer whether you need private cellular in the first place.

Q: Will Wi-Fi 7 fix AMR roaming problems?

A: Potentially, and this is the genuinely new part of the 2026 answer. Multi-Link Operation lets a client hold associations across multiple links rather than making a hard break-before-make switch, which targets the exact roaming gap that stops robots. The caveats are real: 802.11be makes support for both MLO modes mandatory for access-point multi-link devices but optional for client devices, so the robot's radio — not your infrastructure — decides which mode you get; eMLSR is the mode to plan against, since vendors disagree on how widely full simultaneous transmit-and-receive is actually shipping and it is scarcest on the client side; and most AMRs in service today have older radios anyway. Treat it as a reason to re-evaluate a Wi-Fi refresh against private 5G — not as an automatic fix for an existing fleet.

Sources

Author Bio

Nobody hired The Whitepaper Skeptic to design a wireless network, and this article does not pretend otherwise — no RSSI floor, SNR target, or cell-overlap percentage appears anywhere in it. The AMR strategy and vendor evaluation work led at The Won produced a different kind of finding: the wireless layer was the one item no vendor would own. Robot suppliers treated the network as a given, corporate IT treated the robots as one more client type, and deployments stalled in the gap between those two assumptions. Later OT network architecture reviews on the security side answered the question this article ends on, which is who administers the robot network and who gets paged when it degrades.

Search This Blog

Beyond the Whitepaper