Telecom engineering reference for protocols, messages, call flows, troubleshooting, releases, and tools.
Menu
NASLTEUE to MME3GPP TS 24.301
LTE Extended Service Request
Extended Service Request is the EPS NAS message the UE sends when the service request procedure needs the extended LTE NAS form, especially for CS fallback, 1xCS fallback, or packet services via S1.
Message Fact Sheet
Protocol
nas
Network
lte
Spec
3GPP TS 24.301
Spec Section
5.6.1, 8.2.15
Direction
UE to MME
Message Type
EMM signaling
Full message name
LTE Extended Service Request
Protocol
NAS
Technology
LTE
Direction
UE to MME
Interface
N1 over LTE access / S1-MME control path
Signaling bearer / channel
NAS signaling / Commonly carried after LTE access restoration or paging response when the UE needs the extended service-request branch.
Typical trigger
Triggered when the UE needs CS fallback, 1xCS fallback, packet services via S1, or related extended service restoration instead of the basic Service Request branch.
Main purpose
Lets the UE request service restoration with service-type context that is not covered by the basic Service Request message, so the network can continue the correct CS fallback, SMS, or packet-service branch.
Main specification
3GPP TS 24.301, 5.6.1, 8.2.15
Release added
Release 8
Procedures where used
LTE Service Request Procedure, CS Fallback, 1xCS Fallback, Packet Services via S1
What is LTE Extended Service Request in simple terms?
Extended Service Request is the EPS NAS message the UE sends when the service request procedure needs the extended LTE NAS form, especially for CS fallback, 1xCS fallback, or packet services via S1.
Lets the UE request service restoration with service-type context that is not covered by the basic Service Request message, so the network can continue the correct CS fallback, SMS, or packet-service branch.
Why this message matters
Extended Service Request is the LTE NAS message the UE sends when service restoration needs the extended service-type form instead of the basic Service Request message.
Where this message appears in the call flow
Mobile-originated CS fallback request
In a mobile-originated CS fallback branch, Extended Service Request carries the service type that tells the network to continue the fallback-oriented service restore path.
Call flow position: UE-originated extended service-start message sent when the UE needs to restore service for a CS fallback or related fallback branch.
Typical state: The UE already has valid EPS context and is restoring service with CS-oriented service-type context rather than basic packet-service context.
Preconditions:
The UE is EPS-registered.
The service request trigger requires the extended service branch.
Next likely message: Authentication Request, Security Mode Command, Service Accept, or Service Reject
Paging-triggered extended service response
After paging, Extended Service Request carries the extended service context and any CSFB response information the network needs to continue the branch.
Call flow position: UE-originated extended service message sent after paging when the pending service requires the extended branch, including CS fallback acceptance or rejection context.
Typical state: The UE is responding to a paging-triggered restore path and must indicate the correct extended service behavior.
Preconditions:
Paging triggered service restoration.
The pending service requires the extended service-request form.
Next likely message: Authentication or service-restoration continuation
Packet services via S1
When packet services use the extended restore path via S1, Extended Service Request carries the service-type context that replaces the basic Service Request branch.
Call flow position: UE-originated extended service message sent when the network and UE use the extended service-request form for packet services via S1 instead of the basic Service Request message.
Typical state: The UE is restoring packet service with extended service-type context rather than a plain service-request branch.
Preconditions:
The UE is EPS-registered.
The packet-service restore branch is using Extended Service Request.
Next likely message: Service Accept, Service Reject, or common NAS continuation
Interface: N1 over LTE access / S1-MME control path
Domain: Core-side EPS mobility management signaling that restores service using existing EPS context while carrying extended service-type context.
Signaling bearer: NAS signaling
Logical channel: Commonly carried after LTE access restoration or paging response when the UE needs the extended service-request branch.
Transport / encapsulation: EPS NAS message sent by the UE toward the MME through the eNodeB during the service request procedure.
Security context: Normally sent under an existing NAS security context because the UE is already EPS-registered and is restoring service rather than starting fresh attach.
Message Structure Overview
Extended Service Request is an EPS mobility-management message rather than an ASN.1 LTE RRC structure.
The practical reading path starts with Service type, then the UE identity and security-context reference, then any CSFB response or bearer-status context.
In real traces, the key question is why the UE used Extended Service Request instead of the basic Service Request message.
ASN.1 Message Syntax for LTE Extended Service Request
Extended Service Request
Service type
NAS key set identifier
Mobile identity
CSFB response OPTIONAL
EPS bearer context status OPTIONAL
device properties OPTIONAL
How to read this message syntax
Extended Service Request is a NAS layer-3 message, not an ASN.1 LTE RRC message. Read it first from Service type because that field explains why the UE used the extended service branch instead of basic Service Request.
LTE Extended Service Request - Example Dump
Extended Service Request
Protocol discriminator: EPS mobility management
Security header type: Integrity protected and ciphered
Message type: Extended Service Request
Service type: mobile originating CS fallback
NAS key set identifier: 7
Mobile identity: S-TMSI
EPS bearer context status: bearer 5 active
How to read this dump
Start with Service type because it explains the entire branch.
Then inspect the UE identity and stored NAS-context reference to make sure the extended service branch fits the expected registered context.
If paging was involved, inspect CSFB response next because it can change how the network continues or stops CS fallback.
Important Information Elements
IE
Required
Description
Service type
Yes
Tells the network which extended service branch is being requested, such as CS fallback, 1xCS fallback, or packet services via S1.
NAS key set identifier
Yes
References the stored NAS security context used for the service-restoration branch.
Mobile identity
Yes
Carries UE identity context used to continue the existing EPS registration model.
CSFB response
Optional
Indicates whether the UE accepted or rejected the CS fallback branch in paging-triggered cases.
EPS bearer context status
Optional
Lets the UE report its bearer-context view when that matters to later service-restoration handling.
Device properties
Optional
May carry additional UE context relevant to the extended service branch.
Detailed field explanation
Service type
Tells the network which extended service branch is being requested, such as CS fallback, 1xCS fallback, or packet services via S1.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
NAS key set identifier
References the stored NAS security context used for the service-restoration branch.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Mobile identity
Carries UE identity context used to continue the existing EPS registration model.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
CSFB response
Indicates whether the UE accepted or rejected the CS fallback branch in paging-triggered cases.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
EPS bearer context status
Lets the UE report its bearer-context view when that matters to later service-restoration handling.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Device properties
May carry additional UE context relevant to the extended service branch.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
What to check in logs and traces
Confirm why the UE used Extended Service Request instead of Service Request.
Inspect Service type first.
Check whether paging or a mobile-originated CS trigger started the branch.
Inspect CSFB response when the trace involves paging-triggered CS fallback.
Correlate the message with Service Accept, Service Reject, or common NAS continuation.
Common Issues and Troubleshooting
The UE restores service, but the network takes a different branch than expected.
Likely cause: The Service type in Extended Service Request may point to a CS fallback or packet-services-via-S1 branch that differs from the assumed case.
What to inspect: Check Service type first, then correlate it with the surrounding service trigger.
Next step: Treat the message as a branch selector before blaming later service handling.
Likely cause: The UE may be returning different CSFB response values or entering different extended-service branches across traces.
What to inspect: Compare the paging trigger, CSFB response, and later service outcome.
Next step: Read Paging and Extended Service Request together as one restore-service pair.
Packet service restoration uses Extended Service Request in some cases but Service Request in others.
Likely cause: The network support context and the exact procedure conditions may differ across traces.
What to inspect: Compare the returned network capabilities, the service trigger, and whether packet services via S1 is in use.
Next step: Decide first whether the branch should really be basic Service Request or the extended form.
LTE / 5G / Variant Comparison
Compared with Service Request
Service Request is the basic restore-service message. Extended Service Request adds service-type context for CS fallback, 1xCS fallback, or packet services via S1.
Compared with Control Plane Service Request
Extended Service Request restores service using the standard extended LTE NAS branch. Control Plane Service Request is the CIoT-oriented control-plane variant.
Compared with Paging
Paging is the trigger that may wake the UE for mobile-terminated service. Extended Service Request is the UE message that continues the correct extended restore branch after paging.
FAQ
What is Extended Service Request in LTE?
It is the EPS NAS message the UE sends when the service request procedure needs the extended service-type form instead of the basic Service Request message.
What should I inspect first in Extended Service Request?
Start with Service type, because that field explains why the UE used the extended service branch.
Why is Extended Service Request important in troubleshooting?
Because it tells you which service-restoration branch the UE actually asked the network to continue, especially in CS fallback and packet-services-via-S1 cases.
What usually comes after Extended Service Request?
The network may continue with authentication or security procedures, then either accept the restore path with Service Accept or reject it with Service Reject.
Decode this message with the 3GPP Decoder, inspect the related message database, or open the matching call flow to see where this signaling step fits in the full procedure.
