RRC Setup Success Rate looks like a simple KPI. It’s actually a diagnostic map of everything that can go wrong before a UE even gets a radio bearer.
Most engineers treat it as one number. I treat it as five different failure stories wearing the same formula.
The formula, for context:
RRC SSR = (RRC Setup Complete / RRC Setup Request) × 100
Simple ratio. The complexity is in the denominator - every reason a request gets sent, and every reason a response never comes back clean.
Here’s how I break down a degraded RRC SSR on Huawei RAN, in the order I actually check them:
1, Admission Control rejects
Cell hits max RRC connected users or PRB congestion threshold. Symptom: failures cluster during busy hour only, healthy at 3am. Check: VS.RRC.ConnReq.Rej.Cause counters, cross-reference with PRB utilization.
2, Radio link failure before completion
Weak SINR or fast fading kills the UE before RRC Setup Complete reaches the eNB. Symptom: failures correlate with poor RSRP/SINR bins, often edge-of-cell. Check: overlay failure locations against a coverage plot, not just averaged RF KPIs.
3, RandomAccessfailures upstream
If RACH (Msg1-Msg4) isn’t completing, RRC Setup Request may never even land cleanly. This is the one people miss — they debug RRC failures as an RRC problem when the actual break is in preamble collision or PRACH configuration. Check: RACH success rate for the same cell, same window.
4. Transport backhaul congestion
S1 or X2 interface congestion delays or drops the setup complete message on the network side. Symptom: failures spike after a transport change or during backhaul-shared busy hour, RF side looks clean. Check: transport KPIs, not RF KPIs, for this one.
5. Paging vs origination mismatch
Setup requests triggered by paging (mobile terminated) fail differently than mobile-originated ones — different cause code distributions. Lumping them together in one RRC SSR number hides which direction is actually broken.
The Trap:
Optimization teams often throw antenna tilt and power changes at a degraded RRC SSR when the real cause is admission control or transport. RF tuning fixes nothing if the bottleneck isn’t RF.
My actual workflow when RRC SSR drops:
-
Split failures by cause code first, not by cell
-
Check busy-hour correlation before touching antennas
-
Confirm RACH SSR is healthy before trusting RRC failure attribution
-
Only then move to coverage/interference investigation
Quick one for the RF crowd:
when your RRC SSR dips, what’s the first counter you pull - cause code breakdown, RACH SSR, or PRB utilization?
LinkedIn: 