LTE Service Request Procedure Call Flow
LTE Service Request is the procedure that restores active service when the UE is already registered but idle. It is used when downlink data, uplink data, or signaling needs the UE to move from stored EPS context back into active service without running a fresh attach.
If this procedure does not complete cleanly, the UE may remain registered but unavailable for active user traffic or signaling even though the basic EPS registration still exists.
Introduction
The LTE Service Request Procedure reactivates the control-plane and user-plane path for a UE that is already in registered EPS state. It is commonly triggered after Paging, uplink data arrival, or later signaling activity when the UE is in ECM-IDLE.
The main nodes are the UE, eNB, MME, and often SGW. The procedure uses the stored EPS context instead of rebuilding the whole registration state from the beginning.
What Is LTE Service Request in Simple Terms?
- What starts the procedure: The UE needs active service again while valid EPS registration already exists.
- What the UE and network want to achieve: Restore connected signaling and, when needed, the user-plane path without a fresh attach.
- What success looks like: The UE sends Service Request and the network returns the UE to active service with usable bearer continuity.
- What failure means: The UE remains registered but cannot return to active service, or the stored context is treated as unusable and another recovery path is needed.
Why this procedure matters
Service Request is the main bridge between idle registration and active LTE service. It is also the point where paging analysis, NAS security continuity, and bearer reactivation need to be read together.
Quick Fact Sheet
| Procedure name | LTE Service Request Procedure |
|---|---|
| Domain | Idle-to-connected service restoration in EPS |
| Main trigger | Paging response, uplink pending data, or later signaling while valid EPS context already exists |
| Start state | UE is EMM-REGISTERED and usually ECM-IDLE |
| End state | UE is back in ECM-CONNECTED with service restored |
| Main nodes | UE, eNB, MME, SGW |
| Main protocols | RRC, NAS, S1AP, GTPv2-C |
| Main success outcome | Connected signaling and active service are restored using stored EPS context |
| Main failure outcome | Service Reject, security restart, missing bearer restoration, or recovery through another NAS path |
| Most important messages | Paging, Service Request, Initial Context Setup, E-RAB Setup, Service Accept |
| Main specs | TS 23.401, TS 24.301, TS 36.300, TS 36.331, TS 29.274 |
Preconditions
- The UE already has valid EPS registration and stored security context.
- The UE can start a new RRC access attempt when service must be restored.
- The MME can still identify the UE from S-TMSI or other valid temporary identity.
- The bearer context needed for service restoration is still usable or can be reactivated.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Starts access after paging or uplink need and sends Service Request using stored EPS context. |
| eNB | Provides the new radio signaling path and applies the context setup requested by the MME. |
| MME | Validates the stored context, handles NAS continuation, and coordinates bearer restoration. |
| SGW | Participates when the user-plane path needs to be reactivated or updated. |
Interfaces used
| Interface | Endpoints | Role |
|---|---|---|
| LTE Uu | UE <-> eNB | Carries the fresh RRC access leg and the Service Request NAS container. |
| S1-MME | eNB <-> MME | Carries the S1AP control messages and NAS transport. |
| S11 | MME <-> SGW | Updates bearer context when user-plane reactivation is needed. |
| S1-U | eNB <-> SGW | Carries the reactivated user-plane path after service restoration. |
End-to-End Call Flow
UE eNB MME SGW
| | | |
|<-Paging---------|<---------------------------------|
|--RRC Conn Req-->| | |
|<-RRC Conn Setup-| | |
|--RRC Setup Complete + Service Request------------->|
| |--Initial UE Message------------->|
| | |--Modify Bearer------------------>|
| | |<--Modify Bearer Response---------|
|<--Initial Context Setup / Service Accept----------|
|--next uplink NAS continuation-------------------->|Major Phases
1. Idle trigger and access restart
Paging or uplink service need causes the UE to leave idle behavior and create a fresh RRC signaling path.
2. Service Request delivery
The UE sends Service Request using the stored EPS security context and identity.
3. Context validation and bearer restoration
The MME validates the stored context and coordinates the bearer or tunnel path needed for active service.
4. Completion
The eNB applies the context setup and the UE returns to active service in connected state.
Step-by-Step Breakdown
Idle return trigger
Sender -> receiver: Network or UE internal trigger
Message(s): Paging or uplink pending-data condition
Purpose: Decide that idle registered state is no longer enough.
State or context change: UE prepares to move from ECM-IDLE toward ECM-CONNECTED.
Note: Paging success does not prove service restoration success. The next access leg must still complete.
RRC access establishment
Sender -> receiver: UE -> eNB
Message(s): RRC Connection Request, RRC Connection Setup, RRC Connection Setup Complete
Purpose: Recreate the signaling path used for NAS continuation.
State or context change: UE re-enters connected signaling.
Note: A paging-return issue is often really an RRC access issue at this point.
Service Request
Sender -> receiver: UE -> eNB -> MME
Message(s): Service Request
Purpose: Ask the network to restore service using stored EPS context.
State or context change: MME resumes control of the UE service path without a fresh attach.
Note: Check the short NAS format and the identity used in the request.
Context and bearer update
Sender -> receiver: MME -> SGW and MME -> eNB
Message(s): Bearer update signaling, Initial Context Setup, E-RAB setup
Purpose: Restore the active service path.
State or context change: User-plane and radio-side context become usable again.
Note: This is where a clean NAS Service Request can still fail to become real user service.
Important Messages
| Message | Protocol | Sender -> Receiver | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| Paging | RRC | eNB -> UE | Triggers idle return when downlink service is pending. | Paging identity, timing, and whether the UE answers with fresh access. |
| RRC Connection Setup Complete | RRC | UE -> eNB | Carries the NAS Service Request toward the MME. | Dedicated NAS container and correlation with paging or uplink trigger. |
| Service Request | NAS | UE -> MME | Requests restoration of active service using stored EPS context. | Identity, KSI, request type, and whether the stored context looks valid. |
| Downlink NAS Transport | S1AP/NAS | MME -> UE | Carries later NAS continuation such as Service Accept. | Whether the network returned accept, security restart, or failure indication. |
| Uplink NAS Transport | S1AP/NAS | UE -> MME | Carries uplink NAS continuation after service restoration. | Whether the final uplink side reaches the MME after context setup. |
Important Parameters to Inspect
| Item | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| S-TMSI / M-TMSI | Temporary identity used to resume service quickly. | Paging, Service Request, Initial UE Message | Allows the MME to find the stored UE context. | Stale temporary identity, wrong MME context, paging mismatch. |
| NAS KSI | Reference to the stored NAS security context. | Service Request | Shows whether the UE is trying to reuse a valid security state. | Stale KSI, context mismatch, security restart. |
| EPS Bearer and E-RAB IDs | Bearer correlation across EPC and eNB. | Initial Context Setup and bearer restoration | Links NAS recovery to real service availability. | Bearer update failure, partial E-RAB setup, missing user plane. |
| S1AP IDs | MME and eNB UE IDs used on S1-MME. | Initial UE Message and later context setup | Needed for clean multi-interface trace correlation. | Wrong merge assumptions, missing correlation. |
Successful Completion
A successful Service Request returns the UE from idle registered behavior to active service without rebuilding EPS registration from the beginning.
In practical traces, success means the UE reaches ECM-CONNECTED, the radio context is restored, and the bearer path is usable again for pending traffic or signaling.
Common Failures and Troubleshooting
UE receives Paging but service does not return
Likely cause: The UE missed the access restart, or the later Service Request path failed.
Where to inspect: Paging timing, RRC access, Service Request delivery.
Relevant message(s): Paging, RRC Connection Request, Service Request
Relevant interface(s): LTE Uu, S1-MME
Likely next step: Decide whether the break is paging-related or really an access/service-restoration failure.
Service Request is sent but the MME does not continue
Likely cause: Stored context is stale or security continuity is not acceptable.
Where to inspect: Identity, KSI, NAS continuation, MME-side context lookup.
Relevant message(s): Service Request, Security Mode Command, Service Reject
Relevant interface(s): NAS, S1-MME
Likely next step: Check whether the UE should fall back to attach or another recovery path.
NAS path looks successful but user traffic still fails
Likely cause: Bearer or tunnel restoration did not complete cleanly.
Where to inspect: Initial Context Setup, E-RAB result, SGW update.
Relevant message(s): Service Request, Initial Context Setup, bearer update signaling
Relevant interface(s): S1-MME, S11, S1-U
Likely next step: Correlate control-plane success with the restored user-plane path.
What to Check in Logs and Traces
- Confirm the UE was already registered before the Service Request started.
- Correlate Paging or uplink trigger with the later Service Request.
- Check the temporary identity and KSI used in Service Request.
- Verify that the eNB and MME both apply the restored context cleanly.
- Check user-plane restoration before declaring the procedure fully successful.
Related Pages
Related sub-procedures
- LTE Paging Procedure for the downlink trigger that commonly starts idle return.
- LTE Extended Service Request Procedure for CS fallback-related or special service continuation.
- LTE Attach Procedure when stored context is not usable and a fresh registration path is needed.
Related message reference pages
Related troubleshooting pages
Notes
Service Request restores service from stored EPS context. It is not a fresh registration procedure, so the highest-value checks are the paging or idle trigger, the reused security context, and whether bearer restoration really happened.
- Read Service Request together with EMM and ECM states.
- If paging was correct but service still failed, the break is often in the fresh access or bearer-restoration leg.
FAQ
What is LTE Service Request?
It is the procedure that restores active service for a UE that is already registered in EPS but idle.
How is Service Request different from Attach?
Attach creates or rebuilds EPS registration. Service Request reuses stored EPS context and only restores active service.
Does paging always lead to Service Request?
Paging often leads into Service Request, but the real result still depends on fresh RRC access and NAS continuation.
What should I inspect first in a failed Service Request?
Start with the trigger, the fresh RRC access leg, and the temporary identity and KSI used in the request.