Telecom engineering reference for protocols, messages, call flows, troubleshooting, releases, and tools.
Menu
NASLTEUE to MME3GPP TS 24.301
LTE Service Request
Service Request is the EPS NAS message the UE uses to restore a NAS signaling connection and re-establish radio and S1 bearers while valid EPS context already exists.
Message Fact Sheet
Protocol
nas
Network
lte
Spec
3GPP TS 24.301
Spec Section
5.6.1, 8.2.25
Direction
UE to MME
Message Type
EMM signaling
Full message name
LTE 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 during idle-to-connected service restoration after LTE access is re-established
Typical trigger
UE has valid EPS registration context and needs to resume service for mobile-originated data, mobile-terminated paging response, or related service restoration without running a fresh attach.
Main purpose
Lets the UE request service continuation from an EPS-registered state, resume access for mobile-originated or mobile-terminated activity, and prove existing NAS context using the compact service-request structure.
Main specification
3GPP TS 24.301, 5.6.1, 8.2.25
Release added
Release 8
Procedures where used
LTE Service Request Procedure, Idle to Connected Service Restoration, Paging Response, Mobile-Originated Data Resumption
Service Request is the EPS NAS message the UE uses to restore a NAS signaling connection and re-establish radio and S1 bearers while valid EPS context already exists.
Lets the UE request service continuation from an EPS-registered state, resume access for mobile-originated or mobile-terminated activity, and prove existing NAS context using the compact service-request structure.
Why this message matters
Service Request is the UE asking the LTE/EPS network to restore active service using already valid EPS context instead of starting a fresh attach.
Where this message appears in the call flow
Mobile-originated service restoration
In mobile-originated service restoration, the UE re-establishes the LTE access path and sends Service Request so previously valid EPS context can be used to resume service.
Call flow position: UE-initiated service-restoration message sent when uplink user activity needs the EPS connection path to become active again.
Typical state: UE is EPS-registered, idle on the radio side, and is trying to re-enter active service without a fresh attach.
Preconditions:
A valid EPS security and registration context already exists.
The UE has a reason to resume packet service.
Next likely message: Service Accept, Service Reject, or common NAS procedures such as authentication and security continuation
Paging response service restoration
After paging, the UE restores the LTE access path and sends Service Request so the pending mobile-terminated service can continue.
Call flow position: UE-originated service-restoration message sent after the network paged the UE for mobile-terminated activity.
Typical state: UE has received paging and is restoring the NAS signaling connection so the network can continue the pending service.
Preconditions:
The UE is already EPS-registered.
Paging indicated that the network needs the UE to resume service.
Next likely message: Service Accept or later service continuation
Service recovery after idle return
When the UE still has valid EPS context after returning to idle, Service Request is the compact NAS step that restores active service without a fresh attach.
Call flow position: Resume message used when the UE still has valid EPS context but needs to restore active service after returning to idle.
Typical state: UE is not rebuilding registration from scratch; it is proving old context and asking for active service to continue again.
Preconditions:
The UE has usable stored EPS context.
The requested continuation does not require a fresh attach path.
Next likely message: Service Accept, Service Reject, or common NAS procedure continuation
Interface: N1 over LTE access / S1-MME control path
Domain: Core-side EPS mobility management signaling tied to idle-to-connected service restoration when valid EPS context already exists
Signaling bearer: NAS signaling
Logical channel: Commonly carried during idle-to-connected service restoration after LTE access is re-established
Transport / encapsulation: Compact EPS NAS message sent by the UE toward the MME after the UE restores the LTE access path for service continuation
Security context: Service Request relies on existing NAS security context and uses the compact service-request format with KSI, sequence number, and short MAC.
Message Structure Overview
Service Request does not follow the normal full NAS layer-3 message structure.
The practical reading path starts with whether the UE really had valid EPS context and then checks the short service-request fields.
In real traces, this is the bridge between idle EPS registration and restored active service.
ASN.1 Message Syntax for LTE Service Request
Service Request
security header type = service request
KSI and sequence number
message authentication code (short)
How to read this message syntax
Service Request uses the compact NAS service-request format from TS 24.301 rather than a normal full NAS message body or an ASN.1 RRC structure. Read it as a proof-of-existing-context message: KSI, sequence number, and short MAC are the core fields.
LTE Service Request - Example Dump
Service Request
Protocol discriminator: EPS mobility management
Security header type: Service request
KSI and sequence number: native KSI 3, sequence number 0x21
Message authentication code (short): 0x7a4c
How to read this dump
The first useful question is whether Service Request is really appropriate for the context, meaning valid old EPS context still exists.
KSI, sequence number, and short MAC are the high-value fields because they prove the stored NAS context the UE is trying to reuse.
If service restoration fails after paging or uplink activity, this message is often the first NAS checkpoint worth validating.
Important Information Elements
IE
Required
Description
KSI and sequence number
Yes
Identifies the stored NAS security context and carries the sequence number needed for the compact service-request format.
Message authentication code (short)
Yes
Provides the short MAC used by the service-request structure to prove the existing NAS context.
Detailed field explanation
KSI and sequence number
Identifies the stored NAS security context and carries the sequence number needed for the compact service-request format.
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.
Message authentication code (short)
Provides the short MAC used by the service-request structure to prove the existing NAS context.
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.
What to check in logs and traces
Confirm the UE already had valid EPS registration context before the message was sent.
Check whether the trigger was paging response or mobile-originated service activity.
Inspect the KSI and sequence-number context.
Inspect the short MAC validation path if the resume attempt is rejected or security procedures restart.
Correlate the message with Service Accept, Service Reject, or later authentication and security continuation.
Common Issues and Troubleshooting
The UE leaves idle but service still does not restore cleanly.
Likely cause: The Service Request may not match the stored NAS context, or the network may decide that common procedures or rejection handling are needed.
What to inspect: Check whether valid EPS context really existed, then inspect the KSI, sequence-number context, and what the network returned next.
Next step: Treat Service Request as the first restore-context checkpoint before assuming a later bearer or data issue.
Paging is seen, but the network does not continue into active service.
Likely cause: The UE may not have completed the service-request path successfully, or the network may have rejected the resume attempt.
What to inspect: Check Paging, LTE access restoration, Service Request, and whether Service Accept or Service Reject followed.
Next step: Read paging response and Service Request as one combined restore-service story.
The UE runs attach instead of service request in a similar-looking case.
Likely cause: Usable EPS context may no longer exist, so the UE cannot use Service Request and has to rebuild context with Attach Request.
What to inspect: Compare the stored-context assumptions, NAS security context, and whether the UE stayed EPS-registered.
Next step: Decide first whether the trace is a resume path or a rebuild path.
LTE / 5G / Variant Comparison
Compared with Attach Request
Service Request restores active service using valid EPS context. Attach Request rebuilds or creates EPS registration context from the start.
Compared with Service Accept
Service Request is the UE's request to restore service. Service Accept is the network response when that restore path is granted.
Compared with Paging
Paging tells the UE that the network wants it to resume activity. Service Request is the UE message that restores the NAS signaling path after that paging trigger.
FAQ
What is Service Request in LTE?
It is the EPS NAS message the UE sends to restore active service using already valid EPS context.
When is Service Request used instead of Attach Request?
Service Request is used when valid EPS registration and NAS context already exist and the UE only needs to resume active service.
What should I inspect first in Service Request?
Start by confirming that valid stored EPS context existed, then inspect the KSI, sequence number, and short MAC.
Why is Service Request important in troubleshooting?
Because it is the main NAS checkpoint that explains why idle-to-connected service restoration succeeded, triggered common procedures, or was rejected.
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.
