5G Service Request Procedure Call Flow
5G Service Request is the control-plane procedure that restores active service for a UE that is already registered but not currently carrying active traffic.
It joins paging or UE-originated service need, RRC restoration, NAS service signaling, and session or user-plane reactivation into one practical recovery path.
Introduction
The 5G Service Request procedure becomes visible when a UE already has valid 5G registration but needs to move back into active service so traffic can flow again.
It often appears after 5G Paging, together with RRC Resume, or before resumed user-plane activity for an existing PDU session.
What Is Service Request in Simple Terms?
- What starts the procedure: The UE or network needs active service again while the UE already has valid 5G registration context.
- What the UE and network want to achieve: Restore the signaling and user-plane path without rebuilding the entire registration procedure.
- What success looks like: The UE reaches Service Accept and traffic or voice can continue on the expected session path.
- What failure means: The stored context was not enough, and the UE may need broader recovery such as re-registration or session rebuild.
Why this procedure matters
Service Request is one of the main checkpoints between passive reachability and active usable service in 5G. If this path fails, engineers can misread the symptom as paging trouble, session trouble, or radio trouble unless they follow the whole chain.
Quick Fact Sheet
| Procedure name | 5G Service Request Procedure |
|---|---|
| Domain | 5G NR + 5GC service resumption and reachability restoration |
| Main trigger | Downlink data, UE-originated data, mobile-terminated voice, or service restoration after idle or inactive state |
| Start state | UE is already registered but has no active service path for immediate data or voice delivery |
| End state | UE regains active service, the access side is restored, and the required PDU session path becomes usable again |
| Main nodes | UE, gNB, AMF, SMF, UPF |
| Main protocols | RRC, NAS, NGAP, PFCP, user-plane tunnel control |
| Main success outcome | UE is reachable for traffic, QoS context is applied, and the needed user-plane path is active |
| Main failure outcome | Service request is rejected, paging loop continues, or the UE falls back toward broader recovery |
| Most important messages | Paging, RRC Resume or Setup, Service Request, Service Accept, PDU Session Status, UE Context Resume or Setup |
| Main specs | TS 23.502, TS 24.501, TS 38.300, TS 38.331, TS 29.244 |
Preconditions
- The UE is already registered in the 5G system.
- At least one service scenario exists that requires active traffic delivery, such as downlink data, voice, or mobile-originated traffic.
- The access side can either resume the old context or create a new short signaling leg for NAS delivery.
- The AMF still has enough registration and security context to evaluate the service restoration request.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Responds to paging or starts service restoration, sends Service Request, and reapplies access or session context. |
| gNB | Restores or rebuilds the radio signaling path, forwards NAS signaling, and reactivates the user-plane mapping toward the core. |
| AMF | Anchors the service restoration logic, validates UE registration and security context, and coordinates the access-side resume path. |
| SMF | Provides session-side context when the restored service needs active PDU-session state or updated QoS handling. |
| UPF | Becomes the active user-plane endpoint again once the restored service path is complete. |
Interfaces used
| Interface | Path | Role |
|---|---|---|
| NR-Uu | UE <-> gNB | Carries paging response behavior, RRC Resume, or fresh RRC setup before the NAS request reaches core signaling. |
| N1 | UE <-> AMF | Carries the Service Request and the related service result. |
| N2 | gNB <-> AMF | Carries NGAP access restoration, UE context handling, and paging-related signaling. |
| N11 | AMF <-> SMF | Used when service restoration needs session coordination or user-plane refresh. |
| N4 / N3 | SMF <-> UPF and gNB <-> UPF | Reinstate or confirm the data path needed for the restored service. |
End-to-End Call Flow
UE gNB AMF SMF / UPF
| | | |
|<----- Paging ----| | |
|-- RRC Resume/Setup ---------------->| |
|-- Service Request ----------------->| |
| | |-- session checks ->|
| | |<-- context result --|
|<-- Service Accept ------------------| |
|==== Active service / data path restored =================>|Major Phases
| Phase | What happens |
|---|---|
| 1. Trigger detection | Either the network pages the UE because downlink traffic or voice arrived, or the UE itself decides it needs active service again. |
| 2. Access restoration | The UE re-establishes RRC control using resume if possible, or a fresh setup if stored radio context is not enough. |
| 3. NAS service request | The UE sends Service Request so the AMF can validate the registration and security context for active service. |
| 4. Context reactivation | The AMF and access side restore the UE context, and the SMF side may confirm session or QoS details if traffic needs them immediately. |
| 5. Service completion | The network accepts the request, the UE regains active reachability, and user-plane traffic or signaling continues. |
Step-by-Step Breakdown
Service trigger and paging or UE-originated need
Sender -> receiver: Network -> UE or UE internal trigger
Message(s): Paging, internal application trigger, or mobile-originated traffic request
Purpose: Start service restoration because active traffic is needed again.
State or context change: The UE moves from passive reachability into a state where active access must be rebuilt.
Note: Always confirm whether the trigger was network-initiated or UE-initiated before interpreting the later signaling.
RRC path restoration
Sender -> receiver: UE -> gNB
Message(s): RRC Resume path or fresh RRC setup sequence
Purpose: Recreate the signaling path needed to deliver NAS service restoration toward the core.
State or context change: The UE regains control-plane access through the serving gNB.
Note: If resume fails and setup is used instead, the service request may still succeed, but the trace meaning changes.
NAS Service Request delivery
Sender -> receiver: UE -> gNB -> AMF
Message(s): Service Request
Purpose: Ask the AMF to restore active service using the stored registration and security context.
State or context change: The AMF validates whether the UE can move back into active service without broader re-registration.
Note: The service type, PDU session status, and security context reference are the first high-value checks here.
AMF validation and context handling
Sender -> receiver: AMF <-> gNB and optionally AMF <-> SMF
Message(s): UE context resume or setup handling, possible session-side coordination
Purpose: Confirm that the UE context is still valid and the access side can carry the restored service.
State or context change: The network transitions from idle or inactive reachability back into an active service-capable state.
Note: A service-request failure can still be rooted in stale session state or paging mismatch, not only in NAS parsing.
Service Accept and data-path resumption
Sender -> receiver: AMF -> UE and gNB <-> UPF
Message(s): Service Accept, resumed user-plane mapping
Purpose: Confirm successful service restoration and allow traffic delivery again.
State or context change: The UE is service-active, and the required traffic path is usable again.
Note: A clean Service Accept without working data often points to access-side or user-plane reactivation trouble after NAS success.
Important Messages in This Flow
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| Paging | RRC | Network -> UE | Tells the UE that downlink service or reachability restoration is needed. | Track paging cause, timing, and whether the UE actually responds on the expected cell. |
| RRC Resume sequence | RRC | UE <-> gNB | Restores access-side signaling faster when the UE has resumable context. | Check whether resume really succeeded or silently fell back to fresh setup. |
| Service Request | NAS | UE -> AMF | Requests restoration of active service with stored 5G registration context. | Inspect service type, PDU Session Status, and security-related context references. |
| Service Accept | NAS | AMF -> UE | Confirms that the core accepted the service restoration request. | Verify the UE receives it and that the expected session or access state follows. |
| Service Reject | NAS | AMF -> UE | Stops the service-request path when the network cannot continue with the stored context. | Read the rejection cause before deciding whether the problem is registration, policy, or access state. |
Important Parameters to Inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| Service type | Indicates why active service is being requested now. | Service Request | Explains whether the path is mobile-originated data, response to paging, or another service branch. | Wrong service type can misalign the network handling. |
| PDU Session Status | Shows which sessions the UE believes are active or resumable. | Service Request and later session context checks | Helps explain why some traffic returns while other traffic remains blocked. | Mismatch with network session view. |
| 5G-GUTI or stored UE identity | Temporary identity used with stored registration context. | Service Request and access restoration context | Lets the network match the request to the right registered UE. | Stale identity after long idle or context loss. |
| Security context reference | The NAS security linkage used for protected continuation. | Service Request and validation path | Confirms whether the stored security context is still valid for active restoration. | Expired or mismatched security context. |
| Paging context and AMF UE association | The reachability state that existed before service restoration. | Paging, N2 context handling, and Service Request correlation | Separates paging-delivery failures from actual NAS service restoration problems. | Paging on wrong TAC, wrong gNB, or stale AMF context. |
Success Criteria
- The UE successfully restores access-side signaling through resume or setup.
- Service Request reaches the AMF and matches a valid stored registration context.
- Service Accept confirms that active service can continue.
- The required PDU-session path and QoS handling are usable again for real traffic or voice continuation.
Common Failures and Troubleshooting
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| UE is paged but never reaches Service Request | Access restoration failed before NAS delivery. | Paging response timing, resume or setup behavior, and radio quality. | Paging, RRC Resume or Setup | NR-Uu, N2 | Treat the problem as access recovery first, not as a core-only service problem. |
| Service Request is sent but rejected | Stored registration or security context is no longer usable, or policy prevents continuation. | Service Request fields, reject cause, and AMF validation logs. | Service Request, Service Reject | N1, N2 | Decide whether the UE should re-register, retry later, or move to a broader recovery branch. |
| Service Accept arrives but traffic still fails | User-plane reactivation or session-side mapping did not finish cleanly. | N3 or N4 setup state, gNB context restore, and session continuity indicators. | Service Accept, session-related follow-up signaling | N2, N3, N4, N11 | Correlate NAS success with actual user-plane restoration before blaming the application. |
| Paging repeats in a loop | The network keeps trying because the UE never successfully completes active restoration. | Repeated paging attempts, RRC retries, and absent or partial NAS request delivery. | Paging, Service Request | NR-Uu, N2, N1 | Confirm whether the UE is reachable but failing to complete the restore path. |
| UE falls back to broader registration instead of service request | The stored context was lost or no longer trusted. | Whether the UE sends a new registration path after failed service restoration. | Service Reject, Registration Request | N1, N2 | Read the fallback as a context-loss symptom, not just a timing anomaly. |
What to Check in Logs and Traces
- Start with the trigger source: paging, mobile-originated data, or another service-restoration reason.
- Verify whether RRC Resume really succeeded or whether the UE fell back to fresh setup.
- Inspect the service type, PDU Session Status, and NAS protection state in Service Request.
- Correlate Service Accept with the first actual user-plane packets instead of treating NAS success as the end of the story.
- If traffic still fails, inspect N3 and session reactivation before blaming the application layer.
Related Pages
Related sub-procedures
Related message reference pages
Related troubleshooting pages
Notes
Service Request is a family of reachability-restoration behaviors. The quickest way to troubleshoot it is to classify the trigger first, then follow access restoration, NAS outcome, and user-plane recovery in that order.
FAQ
What is the 5G Service Request procedure?
It is the procedure that restores active service for a UE that is already registered but not currently in an actively served data or voice state.
When does Service Request happen?
It typically appears after paging, when downlink traffic arrives, or when the UE needs to send new traffic after idle or inactive reachability.
Does Service Request always mean paging happened first?
No. Paging is common for network-initiated service, but UE-originated traffic can also trigger the procedure.
How is Service Request different from Initial Registration?
Initial Registration builds fresh 5G registration context. Service Request assumes the UE is already registered and only needs active service restored.
What should I inspect first in a failing Service Request trace?
Start with whether the UE actually restored the RRC path, then inspect the Service Request fields, the NAS result, and finally the user-plane reactivation.