LTE NAS Recovery After Radio Failure Call Flow
LTE NAS Recovery After Radio Failure describes the NAS-side procedure path that follows a radio interruption after the UE has already recovered enough access to talk to the network again. In many cases this means a new RRC access leg followed by Service Request or, if stored EPS context is no longer usable, a fallback to a broader re-entry path.
This page focuses on the NAS continuation after radio failure, not on the radio failure itself.
Introduction
Radio recovery and NAS recovery are related but not identical. The radio path may stabilize again, but the UE still needs to prove that stored EPS context is valid before full service can continue.
The main nodes are the UE, eNB, and MME.
What Is LTE NAS Recovery After Radio Failure in Simple Terms?
- What starts the procedure: The radio path failed earlier and the UE now tries to resume NAS service with stored EPS context.
- What the UE and network want to achieve: Restore normal service without rebuilding everything from zero.
- What success looks like: The UE regains access, sends Service Request, and the network restores service.
- What failure means: Stored context is no longer valid and the UE must fall back to a broader recovery branch such as fresh attach.
Why this procedure matters
This page explains why a radio failure can later appear as a NAS recovery problem even after the UE manages to access the cell again.
Quick Fact Sheet
| Procedure name | LTE NAS Recovery After Radio Failure |
|---|---|
| Domain | Post-radio-failure NAS continuation |
| Main trigger | Stored EPS context is reused after radio interruption |
| Start state | Radio failure happened earlier, and the UE has regained enough access to resume NAS signaling |
| End state | Service is restored or the UE falls back to fresh entry |
| Main nodes | UE, eNB, MME |
| Main protocols | RRC, NAS, S1AP |
| Main success outcome | Stored EPS context is accepted and service returns |
| Main failure outcome | Service request fails and broader recovery is needed |
| Most important messages | Service Request, RRC Connection Setup Complete |
| Main specs | TS 24.301, TS 23.401, TS 36.331 |
Preconditions
- The UE had valid EPS context before the radio interruption.
- The UE can regain enough radio access to resume NAS signaling.
- The network still has enough stored context to accept a service-restoration branch.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Restarts access and attempts to recover service using stored EPS context. |
| eNB | Provides the access path that carries the NAS recovery branch. |
| MME | Accepts or rejects the NAS service-restoration attempt. |
Interfaces used
| Interface | Path | Role |
|---|---|---|
| LTE Uu | UE <-> eNB | Carries the fresh access used to restart NAS signaling. |
| S1-MME | eNB <-> MME | Transports the recovered NAS branch to the EPC side. |
| NAS | UE <-> MME | Carries the service recovery request. |
End-to-End Call Flow
UE eNB MME
|-- fresh RRC access ------------->|
|-- RRC Setup Complete + Service Request -->|
| |-- Initial UE Message -->|
| |<-- service recovery -----|
|<-- service restored / fallback decision ---|Major Phases
| Phase | What happens |
|---|---|
| 1. Access restart | The UE rebuilds enough radio signaling to carry NAS again. |
| 2. NAS recovery request | The UE tries to reuse stored EPS context through service request. |
| 3. EPC validation | The MME decides whether the stored context is still valid. |
| 4. Recovery result | Service returns or the UE moves into broader recovery. |
Step-by-Step Breakdown
Step 1: New access for NAS continuation
Sender -> receiver: UE -> eNB
Message(s): RRC setup sequence ending in RRC Connection Setup Complete
Purpose: Recreate the signaling path needed to deliver NAS again.
State or context change: The UE regains a radio control path after the earlier failure.
Note: This part can succeed even if NAS recovery later fails.
Step 2: NAS service recovery attempt
Sender -> receiver: UE -> MME
Message(s): Service Request
Purpose: Ask the network to restore service with stored EPS context.
State or context change: The MME validates the saved mobility and security context.
Note: KSI and temporary identity are the first useful checks here.
Step 3: Recovery result
Sender -> receiver: MME -> UE
Message(s): Service restoration or fallback branch
Purpose: Restore active service or force broader re-entry if context is no longer valid.
State or context change: The UE either returns to normal service or must move into attach or another recovery path.
Note: This is where radio failure turns into a NAS context issue.
Important Messages in This Flow
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| RRC Connection Setup Complete | RRC | UE -> eNB | Carries the new NAS recovery start toward the MME. | Whether the NAS container for recovery is present. |
| Service Request | NAS | UE -> MME | Requests service restoration using stored EPS context. | Temporary identity, KSI, and request type. |
Important Parameters to Inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| Temporary identity | The UE identity used for stored EPS context recovery. | Service Request | Shows whether the old context is still being reused. | Stale identity after failure. |
| NAS KSI | The security context reference used during recovery. | Service Request | Helps the network match the right stored security state. | Invalid KSI or stale security context. |
| Later service result | The outcome after the recovery request reaches the MME. | Post-request signaling | Separates successful context reuse from fallback to attach. | Radio path restored, but NAS recovery still fails. |
Successful Completion
Success means the UE regains active service through stored EPS context without needing to restart with a full new registration procedure.
Common Failures and Troubleshooting
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| Radio access returns, but service request fails | Stored EPS context is no longer valid. | Service Request identity and KSI. | Service Request | NAS, S1-MME | Check whether the UE should have fallen back to attach instead. |
| Recovery loops between access and service request | The UE can access the cell, but the EPC rejects or cannot continue the saved context. | Repeated service-request attempts after new access. | RRC Setup Complete, Service Request | LTE Uu, NAS | Separate radio stability from EPS context validity. |
What to Check in Logs and Traces
- First confirm the UE regained enough access to carry NAS again.
- Inspect temporary identity and KSI in the recovery request.
- Decide whether the failure is still radio-side or already an EPC context problem.
Related Pages
Related sub-procedures
Related message reference pages
Related troubleshooting pages
Notes
NAS recovery after radio failure assumes stored EPS context still exists. If that assumption is wrong, the later branch usually becomes a fresh registration path instead.
FAQ
What is LTE NAS Recovery After Radio Failure?
It is the NAS-side service-restoration path that happens after the UE has already regained enough radio access to talk to the network again.
What is the usual NAS message here?
Service Request is the most common NAS recovery message when stored EPS context is still valid.