Understanding the RRC Connection Setup Chain
The RRC (Radio Resource Control) connection is the gateway to all 5G services. Before a UE can register, establish a PDU session, or exchange user data, it must first complete the RRC connection setup procedure. A failure at this stage means the user gets nothing -- no call, no data, no service.
3GPP defines the RRC connection procedures in TS 38.331 clause 5.3.3 (RRC Setup) and clause 5.3.5 (RRC Reconfiguration). The complete flow involves four RACH messages (Msg1 through Msg4) followed by the RRC Setup Complete. Each step has distinct failure modes and counters.
Operators treat RRC Setup Success Rate (RSSR) as a Tier-1 KPI. Orange France targets ≥99.0% RSSR for their 5G SA network and reported achieving 99.3% nationally in Q4 2025. KT (Korea Telecom) maintains a stricter target of ≥99.5%, achieved through aggressive parameter optimization and AI-driven anomaly detection across their 130,000 NR cells.
The 4-Step RACH Procedure
The Random Access Channel (RACH) procedure is defined in TS 38.321 clause 5.1 and TS 38.213 clause 8. The contention-based procedure has four messages:
| Step | Message | Direction | Channel | Content | Typical Duration |
|---|---|---|---|---|---|
| 1 | Msg1 (Preamble) | UE → gNB | PRACH | Random Access Preamble (selected from 64 sequences) | 1--3 ms |
| 2 | Msg2 (RAR) | gNB → UE | PDSCH (on RA-RNTI) | Timing Advance, UL grant, Temporary C-RNTI | ≤10 ms (ra-ResponseWindow) |
| 3 | Msg3 (RRC Setup Request) | UE → gNB | PUSCH | RRC Setup Request with establishment cause | 1--5 ms |
| 4 | Msg4 (Contention Resolution) | gNB → UE | PDSCH | RRC Setup message with contention resolution ID | 1--10 ms |
After Msg4, the UE sends RRC Setup Complete (which contains the NAS message, typically Registration Request), completing the procedure.
2-Step RACH (MsgA/MsgB)
3GPP Release 16 introduced 2-step RACH (TS 38.321 clause 5.1.1a), which combines Msg1+Msg3 into MsgA and Msg2+Msg4 into MsgB, reducing latency by approximately 50%. However, 2-step RACH requires higher SINR and is typically configured for small cells and indoor scenarios.
RRC Connection Failure Causes by Stage
| Failure Stage | 3GPP Counter (TS 28.552) | Common Root Causes | Impact Level |
|---|---|---|---|
| Msg1 (Preamble not detected) | RA.PreambleDedicated.Att vs RA.PreambleDedicated.Succ | Weak UL coverage, timing misalignment, interference on PRACH | High -- UE invisible to network |
| Msg2 (RAR timeout) | RA.RARMsg2.Att vs RA.RARMsg2.Succ | DL coverage hole, gNB scheduler overload, PDCCH blocking | High -- UE retries, increasing PRACH load |
| Msg3 (UL decode failure) | RRC.ConnEstabAtt.sum partial | UL interference, power headroom exhaustion, timing advance error | Medium -- wastes RACH resources |
| Msg4 (Contention resolution failure) | RRC.ConnEstabAtt.sum - RRC.ConnEstabSucc.sum | Contention collision (two UEs same preamble), DL resource shortage | Medium -- UE must restart entire RACH |
| RRC Setup Complete not received | RRC.ConnEstabSucc.sum vs established connections | UE mobility during setup, protocol error, NAS rejection | Low -- rare in static scenarios |
Key KPI: RRC Setup Success Rate
The fundamental KPI is:
`
RSSR (%) = (RRC.ConnEstabSucc.sum / RRC.ConnEstabAtt.sum) × 100
`
3GPP defines these counters in TS 28.552 clause 5.1.1.1. The counters are further decomposed by establishment cause:
| Establishment Cause | Counter Suffix | Typical Usage | Normal Failure Rate |
|---|---|---|---|
| mo-Signalling | .cause.mo-Signalling | Registration, service request | <0.5% |
| mo-Data | .cause.mo-Data | User-plane data resumption | <0.8% |
| mo-VoiceCall | .cause.mo-VoiceCall | VoNR call origination | <0.3% |
| mt-Access | .cause.mt-Access | Paging response (incoming call/data) | <1.0% |
| mps-PriorityAccess | .cause.mps-PriorityAccess | Priority/emergency access | <0.2% |
| highPriorityAccess | .cause.highPriorityAccess | URLLC, mission-critical | <0.3% |
Worked Example 1: Diagnosing Msg1 Failures (PRACH Issues)
Scenario: Cell NR-7821 on n78 (3.5 GHz) reports RSSR drop from 99.2% to 94.1% over 48 hours. Step 1: Identify failure stage using counters`
Period: 24 hours
RRC.ConnEstabAtt.sum = 12,450
RRC.ConnEstabSucc.sum = 11,715
Failure count = 735 (5.9% failure rate)
RA.PreambleDedicated.Att = 13,200 (more attempts than RRC due to retries)
RA.PreambleDedicated.Succ = 11,880
Msg1 failure count = 1,320 (10% preamble failure rate -- very high)
`
Step 2: Analyse PRACH conditions
`
PRACH configuration index: 148 (Format A1, SCS 30 kHz)
PRACH occasions per frame: 4 (per TS 38.211 Table 6.3.3.2-2)
Root sequence index: 39
Preamble count: 64 (contention-based: 56, dedicated: 8)
`
Step 3: Check for interference
- Scanner data shows external interference on PRACH frequency resources at -95 dBm (8 dB above thermal noise)
- PRACH target received power:
preambleReceivedTargetPower = -104 dBm(TS 38.321) - Interference margin consumed: UEs at cell edge cannot overcome -95 dBm floor
Root cause: External PIM (Passive Intermodulation) interference on PRACH resources from corroded antenna connector.
Fix applied:
- Immediate: Increase
preambleInitialReceivedTargetPowerfrom -104 to -96 dBm (forces UEs to transmit at higher power) - Short-term: Dispatch tower crew to replace corroded jumper cable
- Post-fix: RSSR recovered to 99.4% within 2 hours of jumper replacement
Worked Example 2: Msg2/Msg4 Failures (DL Resource Shortage)
Scenario: Cluster of 6 cells on a dense urban site reports elevated RRC failure during evening busy hour (18:00-21:00), normal performance off-peak. Step 1: Counter analysis (busy hour only)`
Cell NR-2210 (worst cell in cluster):
RRC.ConnEstabAtt.sum (BH) = 4,200
RRC.ConnEstabSucc.sum (BH) = 3,780
RSSR (BH) = 90.0% (target: 99.0%)
RA.PreambleDedicated.Succ = 4,100 (Msg1 success rate 97.6% -- acceptable)
→ Problem is NOT at Msg1 stage
→ Failures occur at Msg2/Msg3/Msg4 stage
`
Step 2: Check PDCCH and scheduler load
`
PDCCH.CCE.Usage.Avg (BH) = 91% (critically high)
DL.TotalPRBUsage.Avg (BH) = 84% (congested)
RRC.ConnMax (BH) = 1,847 simultaneous connections
`
Step 3: Root cause identification
The gNB scheduler cannot allocate PDCCH CCEs for RAR (Msg2) and Contention Resolution (Msg4) messages because the control channel is saturated by existing connected users. This is a capacity-induced RRC failure, not a coverage problem.
Step 4: Resolution- Immediate: Increase PDCCH CORESET duration from 1 symbol to 2 symbols → doubles CCE capacity at cost of ~7% data throughput
- Short-term: Enable Aggregation Level adaptation to pack more DCIs into available CCEs
- Medium-term: Activate carrier aggregation with n1 (20 MHz) to offload 30% of users, reducing PDCCH load on primary carrier
Systematic Troubleshooting Flowchart
The following decision tree guides systematic RRC failure diagnosis:
`
- Check RSSR < target?
└─ Yes → Continue
└─ No → Monitor (no action needed)
- Check Msg1 success rate (RA.PreambleDedicated)
└─ Msg1 failures > 5%?
└─ Yes → UL coverage/interference problem
├─ Check UL RSSI, PRACH interference
├─ Check preamble power settings
└─ Check PRACH configuration conflicts
└─ No → Continue to Step 3
- Check Msg2 delivery (RAR success)
└─ Msg2 failures > 3%?
└─ Yes → DL resource/PDCCH issue
├─ Check PDCCH CCE utilization
├─ Check DL PRB utilization
└─ Check ra-ResponseWindow timer
└─ No → Continue to Step 4
- Check Msg3/Msg4 (contention resolution)
└─ High contention failure rate?
└─ Yes → Too many simultaneous RACH attempts
├─ Increase preamble count (reduce dedicated, increase CBRA)
├─ Add PRACH occasions
└─ Enable 2-step RACH if supported
└─ No → Check UE-side logs for protocol errors
`
RACH Parameter Optimization Reference
| Parameter | 3GPP Reference | Typical Range | Impact on RSSR | Tuning Guidance |
|---|---|---|---|---|
| preambleInitialReceivedTargetPower | TS 38.331 | -120 to -80 dBm | High | Lower = wider coverage but more interference; raise if Msg1 failures high |
| powerRampingStep | TS 38.321 | 2, 4, 6 dB | Medium | Higher = faster convergence but more UL interference |
| ra-ResponseWindow | TS 38.331 | 1--40 slots | High | Too short = unnecessary Msg2 timeouts; too long = delayed retransmission |
| preambleTransMax | TS 38.321 | 3--200 | Medium | Higher = more retries before RRC failure declared |
| ssb-perRACH-OccasionAndCB-PreamblesPerSSB | TS 38.331 | Various | High | Controls PRACH capacity vs overhead tradeoff |
| ra-ContentionResolutionTimer | TS 38.321 | 8--64 ms | Medium | Too short = premature contention resolution failure |
3GPP Specification References
- TS 38.331: RRC protocol specification -- defines all RRC connection procedures, states, and message formats
- TS 38.321: MAC protocol specification -- defines RACH procedure, preamble selection, power ramping, and timing
- TS 38.213 clause 8: Physical layer PRACH procedures -- defines preamble formats, PRACH occasions, and timing relationships
- TS 28.552 clause 5.1.1.1: RRC connection establishment performance counters -- defines
RRC.ConnEstabAttandRRC.ConnEstabSuccdecomposition
Conclusion
RRC connection failures are the most impactful RAN KPI degradation because they block all downstream services. Systematic troubleshooting requires isolating the failure to the correct RACH stage (Msg1 through Msg4) using 3GPP-defined counters from TS 28.552, then applying targeted fixes: antenna/interference correction for Msg1 issues, PDCCH/scheduler optimization for Msg2/Msg4 issues, and RACH capacity tuning for contention problems. Operators maintaining RSSR above 99% achieve measurably lower churn and higher customer satisfaction scores.