AGV Fleet Scheduling Latency 300ms? How IoT Gateway Devices' "5G+TSN" Achieves Synchronized Obstacle Avoidance for 100 Vehicles

1. 10:17 AM. Your warehouse shut down.

Not a power outage. Not a network failure. 100 AGVs collided at the same intersection.

To be precise: 7 of them collided.

But what you saw was the entire warehouse grinding to a halt. Because the dispatch system triggered a global emergency stop.

You stood in the monitoring room, staring at a sea of red alarm icons on the big screen. Your phone rang — the warehouse supervisor: "Boss Wang, today's outbound orders are all stuck. Customers are waiting for their goods."

You said: "What happened?"

He said: "AGVs are jammed again. Same intersection."

You closed your eyes.

This intersection jammed three times last month. Five times the month before. You changed the dispatch algorithm. Added obstacle avoidance sensors. Even repainted the floor markings at that intersection.

Useless.

Because you've been treating a "fake problem" all along.

The real problem isn't at the intersection. It's not the algorithm. It's not the sensors.

It's in a place you can't see — in those 300 milliseconds of data transmission.

2. You think AGVs collide because they're "not smart enough." Actually, it's because they're "not fast enough."

Let me start with a fact that no AGV project manager wants to admit:

Your AGVs' individual obstacle avoidance capability is probably already very strong.

LiDAR: 360-degree scanning. Ultrasonic: close-range backup. Vision cameras: long-range prediction. Single-unit obstacle avoidance response time may already be under 50 milliseconds.

50 milliseconds. Sounds fast, right?

But here's the thing — you have 100 of them.

100 AGVs running in the same warehouse. They're not running independently. They share intersections. They share corridors. They share charging stations.

What does that mean? It means every action by every single AGV needs to be "told" to the dispatch system, which then "tells" the other 99.

"I'm turning left."
"I'm going straight."
"I'm stopping to yield."

This message — from the AGV sending it, to the dispatch system receiving it, to the dispatch system calculating the optimal path, to the command being sent to the other AGVs—

The whole process. Have you measured it?

Most people haven't. Because they assume "it's fast."

But what's the actual measured number?

280 to 350 milliseconds.

We've measured the most extreme case: an e-commerce fulfillment center, 120 AGVs, scheduling latency of 387 milliseconds.

What does 387 milliseconds mean?

An AGV running at 1.5 meters per second. In 387 milliseconds, it has already moved forward 58 centimeters.

Which means: when the dispatch system tells AGV-A "there's a vehicle ahead, please stop," AGV-A has already moved an extra 58 centimeters.

And AGV-B, at the exact same moment, also received the command "you may proceed," and also moved forward 58 centimeters.

Two vehicles — under the dispatch system's "command" — collided with surgical precision.

The dispatch system says: "I told you to avoid!"

The AGV says: "You were too late."

This is the core contradiction of AGV fleet scheduling: it's not that the algorithm isn't smart enough. It's that the communication isn't fast enough. No matter how good the algorithm is, it can't outrun the laws of physics.

3. Where does the 300-millisecond delay come from?

You might say: we're using 5G. Isn't 5G supposedly 1-millisecond latency?

Correct. 5G air interface latency can indeed reach 1 millisecond.

But that's just the "air interface." The path data takes from AGV to dispatch system looks like this:

AGV → WiFi/5G module → Wireless base station → Core network → Edge server → Scheduling algorithm → Same path back → AGV

Every hop adds latency:

See that?

The 5G air interface's 1 millisecond accounts for less than 1% of the entire chain.

What actually eats the latency is the edge server's queuing and the scheduling algorithm's computation time.

100 AGVs sending data simultaneously — the edge server is like a referee with only one mouth. It has to process them one by one.

First come, first served. The rest wait.

And the AGVs that are waiting? They're charging forward in the dark.

The 300-millisecond delay isn't a technology limitation. It's an architecture mistake.

4. TSN: Letting 100 AGVs "Speak at the Same Time, Be Heard at the Same Time"

So what's the solution?

The answer is two letters:TSN.

Time-Sensitive Networking.

Don't let the name scare you. Here's an analogy:

A regular network is like a wet market. Everyone talks at once. Whoever shouts loudest gets heard first. First come doesn't necessarily mean first served. Latecomers might get pushed out.

TSN is like an operating room. Every surgeon enters in sequence, precise to the microsecond. Who cuts first, who cuts second, who must complete what operation at what exact time — all pre-scheduled. No one cuts in line. No one waits.

TSN's core capability is"deterministic latency."

Not "as fast as possible." It's "guaranteed to complete within X milliseconds."

What's X? For AGV scheduling scenarios, TSN can control end-to-end latency within 1 millisecond, with jitter not exceeding 1 microsecond.

What's 1 microsecond? Light travels 300 meters in 1 microsecond.

Which means: 100 AGVs send obstacle avoidance commands simultaneously. The dispatch system receives them all within 1 millisecond, computes them all, and dispatches them all.

No queuing. No waiting. No "you were too late."

M300

4G Global BandIO, RS232/485, EthernetNode-RED, PLC Protocol

5. 5G + TSN + Edge Computing: All Three Pieces Are Non-Negotiable

But TSN alone isn't enough.

You need three things working together:

Piece 1: 5G.Provides high-bandwidth, low-air-interface-latency wireless access.

AGVs can't be wired with Ethernet. 5G is the only wireless solution that simultaneously satisfies "mobility" and "low latency."

But 5G only solves the "last 100 meters." The core network and servers ahead of that are still the bottleneck.

Piece 2: TSN.Provides deterministic network transmission.

TSN runs between the 5G core network and the edge server, ensuring data packets don't queue, don't get lost, don't arrive out of order. Every packet arrives within its predetermined time window.

Piece 3: IoT Gateway Devices.Move the scheduling algorithm from the cloud to the field.

This is the most critical piece.

Traditional architecture: AGV data → 5G → Core network → Cloud server runs scheduling algorithm → Results sent back.

This path takes 100+ milliseconds no matter how fast it is.

Edge computing architecture: AGV data → 5G → TSN →IoT gateway devices run scheduling algorithm locally→ Results dispatched directly.

The cloud only handles global optimization and data analysis. Real-time scheduling is done entirely at the edge.

Latency compressed from 300 milliseconds tounder 8 milliseconds.

8 milliseconds. An AGV moves only 1.2 centimeters in 8 milliseconds.

That distance is fully covered by LiDAR's safety margin.

No collision. No jam. No stop.

6. A Real Retrofit Case: From "Jammed 3 Times a Day" to "180 Days Zero Collision"

An auto parts warehouse in East China. 86 AGVs. Originally used WiFi + cloud dispatch.

Problem: Average 3.2 jams per day. Scheduling latency: 312 milliseconds. Monthly outbound delay loss from downtime: approximately 180,000 yuan.

Retrofit solution: 5G private network + TSN +IoT gateway devices, with scheduling algorithm moved to the edge.

Post-retrofit data:

180 days. Zero collisions.

Not because the AGVs got smarter. Because the dispatch system finally became "faster than" the AGVs.

7. When Selecting, Don't Just Check "Can It Connect to 5G?"

If you're evaluating solutions for AGV fleet scheduling, here are three recommendations:

7.1 Don't just check "supports 5G." Check if "5G + TSN" is supported together.

Many gateways claim 5G support but don't support TSN. Then your latency still won't come down. 5G solves the air interface latency. TSN solves the core network and server-side latency. You need both.

7.2 The scheduling algorithm must be able to run at the edge.

If your scheduling algorithm is still running in the cloud, 5G+TSN is all for nothing. The data still has to make a round trip to the cloud. You must choose a gateway that supports edge AI inference — scheduling algorithm runs locally, results are dispatched locally.

7.3 Must support multi-AGV synchronized clock.

For 100 AGVs to achieve synchronized obstacle avoidance, their "time" must be identical. The error cannot exceed 1 microsecond. This requires the gateway to support the IEEE 1588 PTP precision clock synchronization protocol.

Miss any one of these three, and your AGV fleet will still jam.

When we build solutions for AGV clients, theIoT gateway devicewe use most now is theUSR-M300.

Mentioning it isn't a hard sell. It's because it genuinely packs 5G+TSN+edge AI inference into a box the size of your palm. Supports PTP clock synchronization. Measured scheduling latency under 8 milliseconds. Obstacle avoidance commands for 100 AGVs — all processed locally. No cloud waiting.

And it draws only 8 watts. Hang it next to the AGV charging station. No extra space. No extra power supply.

You spent millions on AGVs. You spent hundreds of thousands on the dispatch system. Don't let 300 milliseconds of latency jam all that money at the intersection.

AGV collisions are never because the vehicles aren't smart enough. It's because the person commanding them reacts too slowly.

IoT gateway devicesare what make the "command" faster than the "vehicles."

100 vehicles. 8 milliseconds. Zero collision.

This is what an AGV fleet should look like.