Physical AI Needs One Shared Map, Not a Billion

Location belongs in the network because centralized location is the better architecture for what Physical AI actually needs. I am in carrier meetings almost every day, and this is the shift in the conversation. For years the location question was about accuracy. Now it is about where positioning should be computed in a world being built for machines, and the answer is the network.

To be precise about the claim: a device should still be able to locate itself. A vehicle does not wait for the network before braking, and every machine needs a way to compute its own position if it loses connectivity. What belongs in the network is the other thing, the thing no device can build alone: where everything is relative to everything else. That is the map.

A fleet needs one shared map, not 50 partial ones

A device computing its own position is solving a single-device problem, and Physical AI is not a single-device problem. It is robots, vehicles, and equipment moving through the same space at the same time, and coordinating them in real time requires a shared, consistent picture of where everything is. Device-side positioning fragments that picture. Put 50 machines on a site, each running its own positioning stack, and you get 50 independent estimates with different sensors, different calibration, different update rates, and different error models. The operator inherits the job of collecting them, reconciling them, and deciding which ones to trust, and every new device class is another integration project.

Network-side positioning removes that whole layer. The network measures every connected device against the same infrastructure and returns position, time, and consistency from one service: one shared map of the operation, independent of who made the device, what operating system it runs, or which application stack sits on top. It is also how the map gets complete: any real operation is full of vehicles, IoT sensors, and connected devices that cannot compute their own location at all. Something has to place them on the map, and the network is the only option that requires nothing new, no tags, no cameras, no added hardware, just the connectivity those assets already have. A port is the clear case today: cranes, trucks, containers, and tools from a dozen vendors, placed on one map by the network they already connect to, with no per-vendor integration. The same holds on a factory floor or an airport ramp. And it is where traffic goes next. A connected vehicle keeps its on-board awareness of what surrounds it, but coordinating an intersection takes every vehicle on one common map, continuously, and the network is the only party positioned to provide that map across every make of car while taking that load off each of them. The value is not each machine knowing where it is. It is the entire operation centrally knowing where all of them are.

Training is the other half, and it may be the bigger one. Physical AI models learn from interactions grounded in the real world: how things actually move, where they actually interact, where flow actually breaks down. That knowledge lives in centralized, time-aligned trajectories across a whole operation, which is exactly what a network-side location layer generates by default. And it changes the economics of training. Models and simulations built on real flows of vehicles and phones through real environments spend their compute on movement that actually happens, instead of burning it exploring paths that are physically impossible or practically absurd. Grounding training in real movement shortens training time and cuts compute cost. Fragmented device estimates, with inconsistent clocks, formats, and error models, never assemble into that dataset without paying the reconciliation cost the network-side layer was built to avoid.

The shared map is the wrong thing to spend device compute on

The other reason is compute. Compute on a robot is highly limited, and it gets more contested as we ask machines to do more. A robot's processor and battery should go to perception, planning, and autonomy. For the 99+ percent of the time a machine is connected, computing its place in the wider operation is work it can hand to the network, and keeping a fallback for the moments it is not costs far less than carrying the whole load all the time.

Offload that work and the device gets its compute and power budget back for higher-value functions, while positioning runs as one service on shared infrastructure: one integration surface, one calibration, one set of estimates with consistent behavior, for everything on the network. And positioning is just the first workload that follows this pattern. Any inference that depends on the relationships between machines, rather than what one machine senses alone, stacks naturally in the same central layer. As connected machines climb into the billions, one service beats a billion stacks.

And the compute savings are the tip of the iceberg. One shared map makes the entire operation more efficient: in our experience so far, roughly 40%. That translates to 40% fewer robots needed, getting the job done 40% faster, or 40% more power budget per charge. When the operation knows where everything on its network is, it can dispatch the closest robot, head off congestion before it forms, and stop spending battery on movement that never needed to happen. At site scale, that recovered energy and time is the larger gain, well beyond the positioning compute itself. Centralized location does not just move a calculation. It gives the whole system the shared state it needs to eliminate waste.

How the network does it

ZaiNar computes position in the network, from signals the network already receives. We use the uplink SRS, the Sounding Reference Signal devices already transmit as a normal part of staying connected. The computation runs in standards-compliant software on the infrastructure. There is nothing to install on the device, no positioning session for the device to run, and no device compute spent to produce the fix.

The network places the devices connected to it in one shared coordinate system, with centimeter-level accuracy indoors, underground, and in the GPS-denied environments where satellite positioning fails. One map, from one service, for everything on the network, with the device spending nothing extra to be on it.

None of it waits on 6G or new hardware. Software-defined radios are already in virtually every modern base station. The network is no longer just a transmission medium. It is a programmable sensing platform, and ZaiNar runs on that infrastructure today.

The location layer belongs in the network

Location on the device was the right design for the app era, when the question was where am I. Physical AI asks a different question, where is everything, and the architecture that answers it continuously is one shared map produced by the network. Owning that layer means operating positioning as a network service: the carrier runs the positioning engine, holds the authoritative map, and exposes location through its own APIs on its own commercial terms. No one else in the stack can offer that, because no one else operates the infrastructure it runs on. That is the foundation layer for Physical AI, and it belongs to the carrier that turns it on.