Network Brain: How Packet Data Finds the Best Route Across a 5G/LTE Network

Every time your phone loads something, a decision gets made hundreds of times a second: which way should this packet go? I spent twenty years in telecom — a good chunk of it at Nokia — building the systems that answer that question. And a few weeks ago, after building a little thing that let you watch a signal travel through a fruit fly's brain, I couldn't stop noticing the resemblance. A brain and a telecom network solve the same problem: keep full visibility of a huge distributed system, and route signals down the best available path, with no single part in charge of the whole thing.

So I built a second interactive — a real one, pointed at telecom. It's the actual path packet data takes across a modern 5G/LTE network, and you can route it, watch its telemetry, and break it. Fire it up above before you read on. The rest of this makes far more sense once you've injected a fault and watched the traffic find its way around.

Let me walk you through what you're looking at.

How a signal actually travels across a 5G/LTE network

Follow one packet from a phone to the content it wants. It crosses four domains.

Access and the RAN. Your device — the UE — talks over the air (the Uu interface) to a Radio Unit (RU) at the cell site. In an O-RAN / Open RAN design the old monolithic baseband (the BBU) is split into three: the RU does the radio and low-PHY, the Distributed Unit (DU) handles the higher PHY, MAC and RLC, and the Centralized Unit (CU) handles PDCP and RRC. Two segment names you must get right here: the link from RU to DU is fronthaul (carried over eCPRI or CPRI, and extremely latency-sensitive), and DU to CU is midhaul (the F1 interface). Together the DU and CU are the disaggregated BBU.

Transport — the backhaul. From the CU, traffic hits a Cell Site Router (CSR) that aggregates the site's RAN traffic onto IP transport. From there it climbs through aggregation into the IP/MPLS backbone. That whole terrestrial stretch — cell site to core — is the backhaul. Increasingly the routers doing this work aren't fixed boxes but vRouters: cloud-native routing running on commodity (COTS) hardware, part of the broader NFV shift. This is where the "best route" gets chosen: when there's more than one path to the core, something has to score them and pick.

The core — the 5G Core. The packet arrives at the UPF (User Plane Function), the anchor point where all user-plane data is forwarded (N3 coming in, N6 going out toward the internet). Here's the distinction that trips people up, and the one the demo makes visible: the UPF is user plane — it carries your data — while the AMF (Access and Mobility Management Function) and SMF (Session Management Function) are control plane. The AMF registers and authenticates your device and manages mobility; the SMF creates the session and programs the UPF over N4. They set up and steer the path. They never carry a single byte of your actual traffic. The packet-data journey runs through the user plane; the control plane is the air-traffic-control tower, not the runway. (In 4G/LTE the equivalents are the MME, S-GW and P-GW; the split idea is the same.)

Service. Finally the UPF hands off to internet peering and a CDN cache. A cache hit answers locally in a few milliseconds; a miss fetches from origin. Then the content comes back the same way.

That's the spine: UE → RU → DU → CU → CSR → vRouter/backbone → UPF → CDN. In the interactive, the "network brain" is simply what scores each candidate route by latency, throughput, jitter and loss and forwards packets down the cheapest one — and re-scores the moment conditions change.

Observability: you can't fix what you can't see

Here's the first thing to try. Turn Telemetry OFF.

The network keeps running. Packets flow. Nothing visibly changes. Now inject a fault — say, backbone congestion on a vRouter. Somewhere, throughput is collapsing and packets are dropping. And here's the point: you cannot tell where. Every hop looks identical. A failing node is indistinguishable from a healthy one. You know something's wrong; you have no idea what.

Now turn telemetry back on. Each hop reports the KPIs that matter for its layer:

RAN — RSRP, SINR, PRB utilization, cell throughput. Is the radio healthy? Is the cell congested?
Transport — latency, jitter, packet loss, link load. Is a backhaul link saturated?
Core — UPF load, PDU session count, goodput. Is the user-plane anchor overwhelmed?
CDN — cache-hit ratio. Are we serving locally or hammering origin?

With telemetry on, the congested vRouter is screaming red — link load pinned near 100%, jitter and loss climbing — while everything upstream and downstream sits green. That gap, between "something is broken somewhere" and "it's that node, right there," is the entire reason observability exists. In a live network it's the difference between a five-minute fix and a five-hour outage with a dozen people on a bridge call guessing. Having built systems both with and without that visibility, I promise you the monitoring is the cheap half.

A troubleshooting workflow: symptom → KPI → hop → fix

Once you can see, fault-finding becomes a discipline instead of a panic. The loop is always the same: notice the symptom, read the KPIs, localize the hop, apply the fix. The demo lets you run it end to end for four classic faults.

Fronthaul link down (eCPRI). Symptom: a cell goes dark — no throughput past the radio. KPIs: RSRP and SINR at the RU are fine, but the DU shows zero active UEs and throughput at zero, with everything upstream green. Localize: the break is exactly at the RU↔DU fronthaul. Fix: fronthaul has no IP-layer detour, so you can't route around it — this one needs a 1+1 protection switch onto the standby fronthaul fibre. (An honest lesson: not every fault self-heals. Some layers have no alternate and demand intervention.)

Backbone congestion (vRouter). Symptom: latency and jitter spike, the stream stutters. KPIs: one backbone vRouter's link load pins at ~99% with loss climbing; RAN and core are clean. Localize: that single transport node. Fix: IP/MPLS reroutes packet data onto the redundant vRouter. A few milliseconds more latency, but jitter and loss recover. The brain picks a new best route.

UPF overload. Symptom: sessions throttle, new PDU setups start failing. KPIs: the UPF's load and session count max out and its goodput craters — while transport latency stays normal. Localize: the user-plane anchor, not the network in front of it. Fix: the SMF re-anchors sessions on a standby UPF and the N3 path is redrawn to it — a failover that never touches the RAN.

Satellite rain-fade (more on that below). Symptom: the satellite link degrades. KPIs: the primary bird's fade margin goes negative and feeder loss climbs, while a second satellite still has margin. Localize: the weather on one Ka feeder, not the ground network. Fix: fail over to the alternate satellite with adaptive coding.

Notice how much of the work is localization. The fix is often mechanical once you know where to point. Observability is what lets you point.

Two use cases where this really earns its keep

NTN — reaching the places fibre doesn't. Non-terrestrial networks put a LEO satellite in the path to cover remote and rural areas. In the demo's NTN scenario a device beyond terrestrial range uses direct-to-cell access up to a satellite, a Ka-band feeder link down to a ground gateway, and satellite backhaul into the same 5G Core. I've kept it honest: the latency is higher than fibre, and the feeder is exposed to rain fade. The interesting part is that the network treats a satellite path as just another route to score — so when one bird fades, the terminal fails over to another, and the core never notices the difference.

Private LTE / 5G for utilities. A power utility can't run grid control over the public internet — SCADA telemetry and control need low, predictable latency and can't depend on a WAN that might drop. So they build a private LTE / private 5G network: their own RU and DU/CU on licensed or CBRS spectrum, feeding an on-prem (edge) UPF that does local breakout. That's the key move. Because the user plane is anchored on-site, substation SCADA traffic stays local at single-digit-millisecond latency — and in the demo, when you cut the WAN link to the enterprise cloud, the grid-control loop doesn't even flinch. The cloud historian goes unreachable and buffers; the control path keeps running. That resilience is the reason to pull the UPF to the edge.

Why "brain" is a fair word

I want to be careful here, because I care more about being accurate than clever. A fly is not running your network, and this is not a simulation of a brain. It's a light analogy between two systems that, under the same pressure, arrived at the same answers:

Full visibility. A brain constantly senses its own state; a network instruments every hop. Neither can act on what it can't perceive.
Choosing the best route. Signals take the path that works, weighed by cost and delay — not one hard-wired track. So does packet data.
Distributed control. No CEO neuron; no master switch. Control-plane functions set sessions up, but forwarding decisions live in the routers and the UPF.
Self-healing. Lose a pathway and traffic reroutes. An outage becomes a detour.

What's real in the interactive is the routing: the "best route" is a genuine live shortest-path computation over current link costs, and it truly recomputes the instant you break or fix something. What's illustrative is the scale — the node counts and the exact telemetry numbers are a legible stand-in sized for a browser, not a capture of any production network. I'd rather tell you that plainly than dress it up.

If you want the piece that started all this, go watch a smell become a memory inside a real fruit-fly brain, neuron by neuron — and for the science underneath it, we can map a whole brain now. Then come back here and break something.

This is also the thinking behind Netavon, the consultancy I run — taking observability and orchestration out of the metaphor and into real telco, satellite/NTN and enterprise systems, where finding the fault fast is the whole job.

The interactive network is my own model — accurate in its architecture (RU/DU/CU, fronthaul/midhaul/backhaul, UPF with AMF/SMF as control plane, NTN and private-LTE breakout) and in its routing, illustrative in its scale. The connectome panel uses the real FAFB fly-brain EM volume in Neuroglancer, alongside the FlyWire whole-brain connectome (Dorkenwald et al., Nature, 2024).