How to Troubleshoot LTE Attach Failures with RRC & NAS Decoding

An LTE attach failure is one of the most disruptive problems a subscriber can experience — and one of the hardest to diagnose without protocol-level visibility. The device simply shows “No Service” or “Emergency Only,” with zero indication of what went wrong at the network layer.

For RF engineers working in the field, the only way to isolate the root cause is to decode the actual NAS and RRC messages exchanged between the UE and the MME during the attach procedure.

This guide walks through the most common LTE attach failure scenarios, the EMM cause codes that identify them, and a practical troubleshooting workflow using decoded signaling.

---

How the LTE Attach Procedure Works

Before diving into failures, a quick recap of the normal flow:

1. RRCConnectionSetup — The UE establishes a radio connection with the eNodeB.
2. AttachRequest (NAS) — Carried inside an RRC UL message, the UE sends its identity (IMSI or GUTI), requested PDN, and security capabilities to the MME.
3. AuthenticationRequest / Response — The MME challenges the UE; the SIM computes a response.
4. SecurityModeCommand / Complete — NAS ciphering and integrity protection are activated.
5. AttachAccept — The MME confirms registration, assigns a GUTI, and activates the default bearer.

A failure at any step produces a different signature in the decoded messages. That signature tells you exactly where the problem lies.

---

Common Attach Failure Scenarios

1. Wrong PLMN or Roaming Not Allowed

The UE sends an AttachRequest with a PLMN that the MME does not serve, or the subscriber’s home network has not established a roaming agreement. The MME responds with AttachReject, EMM Cause #11 (PLMN not allowed) or #13 (Roaming not allowed in this tracking area).

What to check: Verify the PLMN in the AttachRequest matches the serving network. Check SIM provisioning for roaming permissions.

2. SIM / USIM Authentication Failure

The SIM cannot compute a valid authentication response — either the Ki/OPc is mismatched, the SQN is out of sync, or the SIM is damaged. The MME sends AuthenticationReject (no cause code — the message itself is the indicator), or the UE fails to respond altogether.

What to check: Look for an AuthenticationRequest followed by no AuthenticationResponse, or an explicit AuthenticationReject in the downlink.

3. Security Mode Failure

The UE and MME cannot agree on a ciphering or integrity algorithm. This happens with older devices that lack EEA2/EIA2 support, or when the MME security policy is misconfigured. The attach stalls after SecurityModeCommand with no SecurityModeComplete.

What to check: Decode the UE Security Capability IE in the AttachRequest and compare against the algorithms in the SecurityModeCommand.

4. MME Overload or Congestion

The core network is temporarily unable to process new registrations. The MME returns AttachReject, EMM Cause #22 (Congestion) with a back-off timer (T3346). The UE will not retry until the timer expires.

What to check: Decode the T3346 timer value in the reject message. If multiple UEs in the same area get Cause #22, the problem is on the core side.

---

EMM Cause Code Reference Table

When an AttachReject arrives, the EMM Cause IE tells you exactly why. Here are the codes you will encounter most often in the field:

EMM Cause	Value	Meaning	Typical Root Cause
#3	Illegal UE	Device blacklisted or IMEI check failed	IMEI on EIR blocklist
#5	IMEI not accepted	Similar to #3, explicit IMEI rejection	Stolen/blocked device
#6	Illegal ME	Mobile equipment not allowed on network	Device type restriction
#7	EPS services not allowed	Subscription does not include LTE	SIM provisioning error
#11	PLMN not allowed	UE not authorized on this PLMN	Roaming / PLMN config
#12	Tracking Area not allowed	UE not authorized in this TA	TA restriction in HSS
#13	Roaming not allowed in TA	Roaming restriction for this area	Roaming agreement gap
#14	EPS services not allowed in PLMN	LTE barred on this PLMN for subscriber	Subscription mismatch
#15	No suitable cells in TA	All cells in TA are barred for UE	SIB / cell barring issue
#25	Not authorized for CSG	UE not member of Closed Subscriber Group	CSG / femtocell config

---

Step-by-Step Troubleshooting Workflow

Here is the procedure an RF engineer should follow when investigating an LTE attach failure in the field:

Step 1 — Capture the Attach Sequence

Use a protocol capture tool to record the full RRC and NAS exchange. You need at minimum:

• RRCConnectionRequest and RRCConnectionSetup (confirms radio layer is working)
• AttachRequest (NAS, carried in RRCConnectionSetupComplete or ULInformationTransfer)
• Any Authentication messages
• The AttachReject or AttachAccept

With HiCellTek’s real-time Layer 3 decoder, these messages appear live on the device screen as they happen — no laptop, no post-processing.

Step 2 — Identify the Failure Point

Map what you captured to the normal attach flow:

• AttachRequest sent, no response at all? The problem is likely at the radio layer (RRC failure) or S1 interface (eNodeB-MME connectivity).
• AuthenticationReject received? SIM/credential issue — escalate to core/provisioning.
• AttachReject received? Read the EMM Cause code — see the table above.
• SecurityModeCommand sent, no Complete? Algorithm mismatch or UE security issue.

Step 3 — Decode the Key IEs

Once you have the failing message, decode these Information Elements:

• EPS Mobile Identity in AttachRequest — is the IMSI/GUTI correct?
• ESM Message Container — is the PDN Connectivity Request well-formed?
• UE Network Capability — does the UE advertise the required security algorithms?
• EMM Cause in AttachReject — the single most important field for diagnosis.

Step 4 — Correlate with RF Conditions

An attach failure is not always a core network problem. Poor RF conditions can cause:

• RRC setup failure before NAS even starts (low RSRP, high interference)
• Timer expiry during authentication (T3410 timeout due to uplink loss)
• Repeated attach attempts draining battery and creating signaling storms

Always cross-reference the attach failure with RSRP, RSRQ, and SINR at the time of the attempt.

Step 5 — Document and Escalate

For each failure, capture:

• Timestamp and cell ID (PCI, EARFCN)
• The decoded AttachReject with cause code
• RF KPIs at the time of failure
• GPS location if available

This evidence package turns a vague “user can’t connect” complaint into a precise, actionable ticket.

---

Using HiCellTek for Attach Failure Diagnosis

HiCellTek’s protocol decoder supports real-time NAS and RRC decoding on Qualcomm-based Android devices. For attach failure troubleshooting, it provides:

• Live NAS message list showing AttachRequest, Authentication, and AttachReject as they occur
• One-tap decoded view with every IE parsed, including EMM Cause in plain text
• Simultaneous RF KPIs (RSRP, RSRQ, SINR) for radio-layer correlation
• Hex + decoded side-by-side output for expert validation

If you are pasting hex captures from QCAT or another tool, the online hex decoder parses LTE NAS and RRC messages instantly in the browser.

---

Key Takeaways

• LTE attach failures are invisible to end users — only protocol decoding reveals the cause.
• The EMM Cause code in the AttachReject message is the single most diagnostic field.
• A structured workflow — capture, identify failure point, decode IEs, correlate RF, document — turns every attach failure into a solvable problem.
• Tools like HiCellTek bring this visibility directly to the field, without post-processing delays.

When the device says “No Service,” the network is always saying something more specific. Your job is to listen.