Telecom engineering reference for protocols, messages, call flows, troubleshooting, releases, and tools.
Menu
NASLTEMME to UE3GPP TS 24.301
LTE Service Accept
Service Accept is the EPS NAS message the network sends when the service request procedure is accepted and active service can continue using the existing EPS context.
Message Fact Sheet
Protocol
nas
Network
lte
Spec
3GPP TS 24.301
Spec Section
5.6.1, 8.2.34
Direction
MME to UE
Message Type
EMM signaling
Full message name
LTE Service Accept
Protocol
NAS
Technology
LTE
Direction
MME to UE
Interface
N1 over LTE access / S1-MME control path
Signaling bearer / channel
NAS signaling / Commonly carried in downlink NAS transport after the service request procedure is accepted
Typical trigger
Sent when the network accepts the service request procedure and the UE can resume active service without rebuilding registration from scratch.
Main purpose
Confirms successful service restoration, returns any EPS bearer context status synchronization or related service-restoration information, and lets the UE move back into active registered operation.
Main specification
3GPP TS 24.301, 5.6.1, 8.2.34
Release added
Release 8
Procedures where used
LTE Service Request Procedure, Idle to Connected Service Restoration, Paging Response, Mobile-Originated Data Resumption
Service Accept is the EPS NAS message the network sends when the service request procedure is accepted and active service can continue using the existing EPS context.
Confirms successful service restoration, returns any EPS bearer context status synchronization or related service-restoration information, and lets the UE move back into active registered operation.
Why this message matters
Service Accept is the network telling the UE that service restoration succeeded and that active LTE/EPS service can continue using the existing context.
Where this message appears in the call flow
Mobile-originated service restoration acceptance
In mobile-originated service restoration, Service Accept confirms that the existing EPS context was sufficient and that active service can continue again.
Call flow position: Network acceptance message sent after the UE requested service restoration from an EPS-registered idle state.
Typical state: UE has already proved or refreshed enough NAS context for the network to restore active service.
Preconditions:
The UE sent Service Request with usable stored EPS context.
The network accepted the service restoration path.
Next likely message: Protected service continuation
Paging response service restoration acceptance
After paging, Service Accept closes the restore path and lets the pending service continue using the restored NAS connection.
Call flow position: Acceptance message sent after the UE restored access in response to paging and the network can continue the pending service.
Typical state: UE is moving from paged idle state back into active service using existing EPS context.
Preconditions:
Paging triggered the restore path.
The service request continuation was accepted by the MME.
Next likely message: Mobile-terminated service continuation
Service recovery after idle return
When the UE still has valid stored EPS context after idle return, Service Accept confirms the restore path without forcing a fresh attach.
Call flow position: Service-restoration acceptance used when the UE still had valid EPS context after returning to idle.
Typical state: UE is returning to active service without attach rebuild.
Preconditions:
Valid stored EPS context still existed.
The resume path was accepted rather than rejected.
Interface: N1 over LTE access / S1-MME control path
Domain: Core-side EPS mobility management signaling that closes the service request procedure and restores active service using existing EPS context
Signaling bearer: NAS signaling
Logical channel: Commonly carried in downlink NAS transport after the service request procedure is accepted
Transport / encapsulation: EPS NAS message sent by the MME and delivered to the UE through the eNodeB in response to Service Request, Extended Service Request, or Control Plane Service Request
Security context: Normally sent under NAS security after the UE has already proved or refreshed the stored EPS context used for service restoration.
Message Structure Overview
Service Accept is an EPS mobility-management message rather than an ASN.1 LTE RRC structure.
The practical reading path starts with whether the restore path was accepted at all, then moves into bearer-context synchronization and any optional service-restoration information.
In real traces, this is the message that closes the NAS service-request loop and explains what active-service state the network expects next.
ASN.1 Message Syntax for LTE Service Accept
Service Accept
EPS bearer context status OPTIONAL
T3448 value OPTIONAL
EPS additional request result OPTIONAL
Forbidden TAI(s) for the list of roaming OPTIONAL
Forbidden TAI(s) for regional provision of service OPTIONAL
How to read this message syntax
Service Accept is a NAS layer-3 message, not an ASN.1 LTE RRC message. Read this NAS syntax from the service-restoration outcome downward, then inspect any bearer-context synchronization or optional timer and forbidden-TAI information that changes later UE behavior.
LTE Service Accept - Example Dump
Service Accept
Protocol discriminator: EPS mobility management
Security header type: Integrity protected and ciphered
Message type: Service Accept
EPS bearer context status: EPS bearer 5 active, EPS bearer 6 active
EPS additional request result: no additional request pending
How to read this dump
The first useful question is whether Service Accept appears cleanly after Service Request or whether the network detoured into additional NAS procedures first.
EPS bearer context status is one of the highest-value fields because it may silently explain why some bearer state was synchronized or locally cleared.
If T3448 is present, it changes how control-plane user-data continuity should be interpreted after acceptance.
Important Information Elements
IE
Required
Description
EPS bearer context status
Optional
Lets the network synchronize bearer-context state by indicating which EPS bearers it considers active or inactive.
Provides control-plane user-data congestion timing when that feature is in use.
EPS additional request result
Optional
Returns the outcome of specific additional EPS requests associated with the service restoration path.
Forbidden TAI(s) for roaming
Optional
May provide updated forbidden tracking-area information in relevant access conditions.
Forbidden TAI(s) for regional provision of service
Optional
May provide updated regional forbidden-area information in relevant access conditions.
Detailed field explanation
EPS bearer context status
Lets the network synchronize bearer-context state by indicating which EPS bearers it considers active or inactive.
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.
T3448 value
Provides control-plane user-data congestion timing when that feature is in use.
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 additional request result
Returns the outcome of specific additional EPS requests associated with the service restoration path.
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.
Forbidden TAI(s) for roaming
May provide updated forbidden tracking-area information in relevant access conditions.
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.
Forbidden TAI(s) for regional provision of service
May provide updated regional forbidden-area information in relevant access conditions.
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 Service Accept follows the correct Service Request path.
Check whether the restore attempt came from paging response or mobile-originated activity.
Inspect EPS bearer context status if bearer continuity looks inconsistent.
Inspect T3448 and EPS additional request result when control-plane user-data behavior matters.
Correlate the message with the start of active service continuation.
Common Issues and Troubleshooting
Service Request appears successful but active service still behaves inconsistently.
Likely cause: Service Accept may include bearer-context synchronization or optional service-restoration information that changes the resulting service state.
What to inspect: Check Service Accept for EPS bearer context status, T3448, and other optional restore-path information.
Next step: Read Service Request and Service Accept as one restore-service pair instead of treating the accept as only a generic success flag.
Paging response reaches NAS restore, but the later service still does not continue correctly.
Likely cause: The restore path may have been accepted, but the returned bearer or forbidden-TAI state may have changed what the UE does next.
What to inspect: Check Paging, Service Request, Service Accept, and any returned synchronization fields together.
Next step: Treat the path as a full restore-service sequence, not only a paging-response acknowledgment.
The network accepts some service restores but rejects or delays others.
Likely cause: The UE may have different stored EPS context, different bearer-state synchronization needs, or different optional request context.
What to inspect: Compare the Service Accept IE set across working and failing cases, especially bearer-context status and optional result fields.
Next step: Use Service Accept as the checkpoint that shows what restored service state the network actually granted.
LTE / 5G / Variant Comparison
Compared with Service Request
Service Request is the UE's restore-service request. Service Accept is the network response when that restore path is granted.
Compared with Service Reject
Service Accept grants service restoration using existing EPS context. Service Reject ends the restore attempt and returns the failure branch the UE must follow.
Compared with Attach Accept
Service Accept restores active service using already valid EPS context. Attach Accept creates fresh EPS registration context.
FAQ
What is Service Accept in LTE?
It is the EPS NAS message the network sends when the service request procedure is accepted and active service can continue using the existing EPS context.
What should I inspect first in Service Accept?
Start with whether the service-restoration path was accepted directly, then inspect EPS bearer context status and any optional restore-path information.
Why is Service Accept important in troubleshooting?
Because it shows not just that the restore path succeeded, but also what synchronized bearer or optional service state the network returned.
What usually comes after Service Accept?
The UE moves into active registered service continuation, subject to any bearer-context synchronization or optional result fields returned in the message.
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.
