LTE Extended Service Request Procedure Call Flow
LTE Extended Service Request is the NAS procedure used when the UE needs service continuation that does not fit the normal Service Request path, especially in CS fallback-related scenarios.
It is commonly used when the UE is already registered in EPS but must trigger a service branch tied to legacy-domain interaction or other extended continuation rules.
Introduction
The LTE Extended Service Request Procedure reuses existing EPS registration but requests a special service continuation path instead of a plain user-service restore. It often appears together with CS fallback, CS paging response continuation, or related SGs-driven behavior.
The main nodes are the UE, eNB, MME, and in many cases the MSC/VLR on the legacy side.
What Is LTE Extended Service Request in Simple Terms?
- What starts the procedure: The UE needs a service continuation path that is not handled by normal Service Request alone.
- What the UE and network want to achieve: Restore service and steer the session into the correct extended or CS-related continuation branch.
- What success looks like: The UE sends Extended Service Request and the network returns the expected continuation path.
- What failure means: The UE stays registered but the expected CS-related or special service continuation does not proceed.
Why this procedure matters
Extended Service Request is one of the main checkpoints between EPS registration and legacy-interworking behavior. It is where idle return, SGs handling, and service type must be read together.
Quick Fact Sheet
| Procedure name | LTE Extended Service Request Procedure |
|---|---|
| Domain | EPS service restoration with special or CS-related continuation |
| Main trigger | CS fallback-related continuation, CS paging response, or other extended service need |
| Start state | UE is already EPS-registered and usually idle |
| End state | UE reaches the intended extended service continuation or is redirected into another recovery path |
| Main nodes | UE, eNB, MME, MSC/VLR |
| Main protocols | RRC, NAS, S1AP, SGs |
| Main success outcome | Special service continuation is accepted and the next voice or legacy step can proceed |
| Main failure outcome | Extended service is rejected, stalled, or redirected into another branch |
| Most important messages | Paging, Extended Service Request, CS Service Notification, NAS continuation |
| Main specs | TS 23.272, TS 23.401, TS 24.301, TS 29.118 |
Preconditions
- The UE already has valid EPS registration.
- The UE can start fresh RRC access for the service continuation attempt.
- The MME has enough stored context to process the special service request.
- If the scenario depends on CS fallback, the SGs-side context must exist or be restorable.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Starts the extended service branch after the trigger that requires it. |
| eNB | Provides the fresh radio signaling path used for NAS continuation. |
| MME | Evaluates the request type and chooses the special continuation path. |
| MSC/VLR | Handles legacy-side continuity when the scenario depends on CS fallback or SGs interaction. |
Interfaces used
| Interface | Endpoints | Role |
|---|---|---|
| LTE Uu | UE <-> eNB | Carries the fresh access leg and NAS request container. |
| S1-MME | eNB <-> MME | Carries the NAS request and continuation. |
| SGs | MME <-> MSC/VLR | Carries the legacy-side continuation for CS-related scenarios. |
End-to-End Call Flow
UE eNB MME MSC/VLR
| | | |
|<-Paging---------|<---------------------------------|
|--RRC Conn Req-->| | |
|<-RRC Conn Setup-| | |
|--RRC Setup Complete + Extended Service Request---->|
| |--Initial UE Message------------->|
| | |----SGs handling------------------>|
| | |<---SGs result---------------------|
|<--NAS continuation / CS Service Notification-------|
|--next service branch continues--------------------->|Major Phases
1. Special service trigger
Paging or UE-side service need triggers a branch that requires Extended Service Request instead of normal Service Request.
2. NAS request delivery
The UE sends Extended Service Request through the fresh RRC signaling path.
3. SGs or legacy continuation handling
The MME checks the service type and coordinates the needed continuation toward the legacy side when required.
4. Result delivery
The UE receives the continuation result and moves into the next CS fallback or related service branch.
Step-by-Step Breakdown
Trigger and access restart
Sender -> receiver: Network or UE trigger, then UE -> eNB
Message(s): Paging or other service trigger, then RRC access
Purpose: Open a fresh signaling path for the extended NAS branch.
State or context change: UE moves from idle or stored context into active signaling.
Note: The trigger must match the service type later seen in the request.
Extended Service Request
Sender -> receiver: UE -> MME
Message(s): Extended Service Request
Purpose: Ask for the special service continuation path.
State or context change: The MME selects a service branch that is different from plain Service Request handling.
Note: Read the service type first, then validate the later SGs or CS behavior.
Legacy-side continuation
Sender -> receiver: MME -> MSC/VLR
Message(s): SGs handling and related service continuation
Purpose: Carry the request into the correct legacy-side branch.
State or context change: The continuation is either accepted, redirected, or blocked.
Note: A clean EPS-side request can still fail here if the legacy-side context is missing.
Important Messages
| Message | Protocol | Sender -> Receiver | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| Paging | RRC | eNB -> UE | Triggers idle return for special service continuation. | Paging identity and whether the next branch is really extended service. |
| Extended Service Request | NAS | UE -> MME | Requests the special service continuation path. | Service type and whether the request matches the scenario. |
| CS Service Notification | NAS | MME -> UE | Indicates CS-related service continuation in some scenarios. | Relation to paging and later CS fallback behavior. |
| Downlink NAS Transport | S1AP/NAS | MME -> UE | Carries NAS continuation back to the UE. | Accept, reject, or continuation result. |
Important Parameters to Inspect
| Item | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| Service type | The requested continuation type in Extended Service Request. | Extended Service Request | Shows why normal Service Request handling is not enough. | Wrong service type, wrong test expectation. |
| Temporary identity | Identity used to resume the stored EPS context. | Extended Service Request and initial uplink signaling | Needed for fast context lookup at the MME. | Stale S-TMSI or wrong MME context. |
| SGs continuity result | The legacy-side outcome tied to the request. | SGs handling and later NAS result | Explains whether the special service branch can continue. | Missing SGs association, MSC/VLR limitation. |
Successful Completion
A successful Extended Service Request returns the UE to connected signaling and hands the session into the intended special service or CS-related continuation path.
Common Failures and Troubleshooting
Wrong branch after paging
Likely cause: The UE or network used normal Service Request behavior when the scenario needed the extended branch.
Where to inspect: Paging trigger, NAS request type, SGs-side context.
Relevant message(s): Paging, Extended Service Request, Service Request
Relevant interface(s): LTE Uu, NAS, SGs
Likely next step: Confirm the service type and legacy-service expectation before troubleshooting deeper.
Extended Service Request reaches the MME but no continuation follows
Likely cause: Legacy-side context or SGs handling is missing.
Where to inspect: MME decision, SGs association, MSC/VLR result.
Relevant message(s): Extended Service Request, CS Service Notification
Relevant interface(s): NAS, SGs
Likely next step: Correlate the EPS-side request with the legacy-side continuation result.
What to Check in Logs and Traces
- Confirm that the request is really Extended Service Request and not normal Service Request.
- Check the service type and the trigger that led into the procedure.
- Correlate the EPS-side request with SGs or legacy-side continuation.
- Follow the next procedure after acceptance instead of stopping at the NAS request itself.
Related Pages
Related sub-procedures
Related message reference pages
Related troubleshooting pages
Notes
Extended Service Request is a special continuation path, not just a longer Service Request. The key check is whether the request type, paging trigger, and SGs or legacy expectation all match the same scenario.
FAQ
When is Extended Service Request used?
It is used when the UE needs a special service continuation path, often tied to CS fallback or related legacy interaction.
How is it different from normal Service Request?
Normal Service Request restores plain active service. Extended Service Request steers the flow into a specific special-service branch.
What should I inspect first?
Start with the request type and service type, then correlate the SGs or legacy-side result.