The diagnostic order that actually works
"User cannot attach" is the most common ticket in any 5G operations team, and the most common reason for wasted hours is engineers jumping straight to the core. Ninety percent of attach failures are radio. Work outward from the UE.
The order I follow:
- Did the UE see the cell? (SSB, MIB, SIB1)
- Did Msg1 (PRACH) succeed?
- Did Msg2/Msg3/Msg4 complete? (RRC Setup)
- Did NAS Registration Request reach the AMF?
- Did the AMF reject, or did the procedure time out?
Nothing further down matters until the previous step is confirmed.
Step 1: Cell selection and SIB acquisition
If the UE is not even camping, you have a coverage or barring problem. Check on the UE side (QXDM, Nemo, TEMS) for:
- SSB-RSRP. Below -115 dBm and the UE will not decode SIB1 reliably.
cellBarredin MIB — ifbarred, the cell is intentionally locked out.intraFreqReselectionandq-RxLevMinin SIB1.- PLMN list in SIB1 — wrong PLMN ID and the UE silently moves on.
On the gNB side, check the cell admin state and the broadcast PLMN list. A surprising number of attach failures are because someone changed PLMN-IdentityList during a config push and forgot to restore it.
Step 2: PRACH failures (Msg1)
Msg1 failures show up as Random Access Problem on the UE and as zero or low PRACH detection counters on the gNB. Vendor counter names vary:
| Vendor | Counter |
|---|---|
| Ericsson | pmRaAttCbra, pmRaSuccCbra |
| Nokia | RACH_STP_ATT, RACH_STP_SUCC |
| Huawei | N.RA.Att, N.RA.Succ |
If attempts are high but successes are low, you are losing Msg2 (RAR) — usually a coverage or interference problem. Check PRACH detection threshold and whether neighbour cells are using overlapping root sequences. 3GPP TS 38.211 Section 6.3.3.1 governs the root sequence allocation; misconfiguration causes false detections.
Common PRACH causes
- Wrong
prach-ConfigurationIndexfor the band/duplex mode - Power ramping never reaches gNB threshold (UE max power vs gNB sensitivity)
- Excessive PRACH preamble collisions in dense cells — increase number of CB preambles
- TA out of range (cells with radius > 14 km using the wrong PRACH format)
Step 3: RRC Setup failures (Msg3/Msg4)
If Msg1 succeeds but RRC Setup never completes, look at:
pmRrcConnEstabAttvspmRrcConnEstabSucc(Ericsson naming)- Failure causes broken out by reason: congestion, radio failure, no reply
A common pattern in 2026 deployments is RRC Setup Reject with cause wait-time due to admission control limits. If you see this on a healthy cell, check the configured max RRC connections and active UE count. SA cells with combined eMBB and FWA traffic hit this earlier than expected.
Step 4: NAS Registration reaches AMF
Once RRC Setup completes, the UE sends Registration Request inside RRC Setup Complete. The gNB wraps it in NGAP InitialUEMessage. If you see RRC Setup Complete on the gNB but no NGAP InitialUEMessage on N2, you have a transport issue — SCTP association down, AMF unreachable, or a routing problem.
Check the SCTP association state on the gNB CLI and the AMF side. NGAP setup failure leaves the gNB unable to forward NAS even if radio is fine.
Step 5: AMF rejects
This is where 5GMM cause codes earn their keep. From 3GPP TS 24.501 Section 9.11.3.2:
| Cause | Meaning | Typical fix |
|---|---|---|
| #3 | Illegal UE | IMEI blacklisted or auth permanent failure |
| #6 | Illegal ME | EIR check failed |
| #7 | 5GS services not allowed | Subscription does not include 5GS |
| #9 | UE identity cannot be derived | SUCI decryption failed at AUSF/UDM |
| #11 | PLMN not allowed | UE roaming agreement missing |
| #12 | Tracking area not allowed | TAI not in allowed list |
| #13 | Roaming not allowed in this TA | TAI restriction |
| #15 | No suitable cells in TA | UE goes to limited service |
| #22 | Congestion | AMF overload control active |
| #27 | N1 mode not allowed | UE forced to EPS fallback |
| #72 | Non-3GPP access not allowed | WLAN/non-3GPP path blocked |
Cause #11 and #13 always point at HSS/UDM subscription or roaming policy. Cause #22 means the AMF itself is rejecting — check overload start counters and consider whether the AMF needs scale-out.
Step 6: Authentication and security failures
If the UE fails authentication, the symptom is usually a NAS Authentication Reject or repeated Authentication Request loops. Possible causes:
- SQN out of sync between USIM and UDM/ARPF — the UDM should issue an
AUTSresync, but some early UDM implementations did not handle it cleanly. Check AUSF logs forAV_GENERATION_PROBLEM. - Wrong K (subscription provisioning error) — the SUCI resolves but the MAC verification fails.
- HN public key mismatch — operator rotated the home network key but UICC still has the old one. Common after security audits.
Step 7: PDU session failure (after registration succeeds)
If registration completes but the UE never gets data, you have a PDU session establishment failure, not an attach failure. Look at SMF and UPF logs and 5GSM cause codes (TS 24.501 Section 9.11.4.2). Cause #29 (User authentication or authorization failed) and cause #31 (Request rejected, unspecified) are the usual suspects, with the latter being an SMF saying "check my logs."
A short diagnostic checklist
> Always confirm in this order: UE radio quality, PRACH counters, RRC Setup counters, NGAP transport, NAS cause code, AUSF/UDM logs.
- Does another UE attach to the same cell? (isolates UE vs network)
- Does the same UE attach to a neighbour cell? (isolates cell vs core)
- Does the same UE attach in a different TAI? (isolates TAI policy)
These three questions usually solve the ticket before anyone opens a PCAP.
Takeaway: Attach failures are a layered problem — diagnose outward from the UE, and never look at the core until you have proven the radio worked.