The RAN Engineer’s Troubleshooting Pyramid

I have seen this pattern many times: a KPI drops, someone opens the RF planning tool, and two days later the tilts have changed while the real issue was an alarm nobody checked.

That is why I like to think about RAN troubleshooting as a pyramid. You start at the base and only move up when the lower layer is clean.

• Base: Alarms and hardware come first, because a faulty radio, a VSWR alarm or a failed board can explain almost any degradation above it.
• Then transport and sync, where backhaul drops, latency spikes or a GNSS holdover can look exactly like a radio problem.
• Next, configuration and parameters, checking recent changes, wrong neighbor definitions or a feature activated without audit.
• After that, RF: coverage, interference, SINR and overshooting, the layer most teams jump to first.
• Then capacity, because a well tuned cell can still collapse when PRB utilization keeps growing.
• At the top sits the user experience, with mobility, VoNR or throughput complaints that make sense only once everything below is clean.

The order matters because every layer can mask the one above it. Tuning RF on a site with a sync issue only moves the problem around, and adding capacity to a misconfigured cell just spends money.

This is also how good SON and automation logic should be built. Before an algorithm touches tilt or power, it should confirm the lower layers are healthy. Without those guardrails, automation optimizes on top of noise.

Fast troubleshooting usually comes from discipline in the sequence, more than from deep knowledge in a single layer.

#RAN #RANOptimization #Troubleshooting #RFOptimization #SON #5G