5G UE-Initiated Connection for Mobile-Originated Data Call Flow
5G UE-initiated connection for mobile-originated data is the practical call flow where a registered UE needs to send new uplink traffic while it is in idle or inactive reachability.
It combines RRC restoration, NAS Service Request, and reactivation of the user-plane path so the waiting uplink traffic can leave the device.
Introduction
This procedure is one of the most common real-world branches of the 5G Service Request family.
The trace usually starts with a UE-side application trigger instead of paging. Analysis becomes easier when you treat it as an uplink-driven service restoration problem rather than as a generic registration event.
What Is UE-Initiated Connection for Mobile-Originated Data in Simple Terms?
- What starts the procedure: A registered UE has new uplink data to send.
- What the UE and network want to achieve: Restore active service without rebuilding the full registration procedure.
- What success looks like: The UE sends Service Request, receives Service Accept, and uplink data flows.
- What failure means: The stored access, security, or session context was not enough for resumed service.
Why this procedure matters
This is the everyday path that turns a registered but passive UE back into an actively transmitting endpoint. It is a high-value troubleshooting workflow because a failure can hide in RRC, NAS, or the restored user plane while the application symptom simply looks like uplink data timeout.
Quick Fact Sheet
| Procedure name | 5G UE-Initiated Connection for Mobile-Originated Data |
|---|---|
| Domain | 5G NR + 5GC service resumption for uplink traffic |
| Main trigger | UE application has uplink data while the UE is in idle or inactive reachability |
| Start state | UE is registered but not in an actively served state for immediate user-plane transfer |
| End state | UE has restored access, received service authorization, and can send uplink data on the needed PDU session |
| Main nodes | UE, gNB, AMF, SMF, UPF |
| Main protocols | RRC, NAS, NGAP, PFCP, user-plane tunnel activation |
| Main success outcome | UE sends Service Request, receives Service Accept, and data starts flowing uplink |
| Main failure outcome | Service restoration fails, user-plane path stays blocked, or the UE falls back to registration recovery |
| Most important messages | RRC Resume or Setup, Service Request, Service Accept, session state checks |
| 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 5GS.
- At least one relevant PDU session exists or can be resumed for the uplink traffic.
- Stored security and registration context are still available for service restoration.
- The access side can provide either resumable or fresh signaling context toward the AMF.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Detects uplink data demand, restores access signaling, sends Service Request, and resumes packet transfer. |
| gNB | Re-establishes the control path, relays NAS signaling to the AMF, and reinstates the radio and user-plane mapping. |
| AMF | Validates that the registered UE may return to active service and coordinates access-side resumption. |
| SMF | Confirms or refreshes session-side details when the resumed uplink path needs active session context. |
| UPF | Receives the restored N3 path and resumes forwarding the uplink user traffic once service is active. |
Interfaces used
| Interface | Path | Role |
|---|---|---|
| NR-Uu | UE <-> gNB | Carries RRC resume or setup and uplink NAS delivery. |
| N1 | UE <-> AMF | Carries Service Request and Service Accept. |
| N2 | gNB <-> AMF | Carries UE context handling and access restoration coordination. |
| N11 | AMF <-> SMF | Used if session context must be checked before uplink data can continue. |
| N3 / N4 | gNB <-> UPF and SMF <-> UPF | Restore or confirm the user-plane path needed for uplink packets. |
End-to-End Call Flow
UE gNB AMF SMF / UPF
| | | |
|-- uplink trigger | | |
|-- RRC Resume/Setup ---------------->| |
|-- Service Request ----------------->| |
| | |-- session checks ->|
| | |<-- session ready ---|
|<-- Service Accept ------------------| |
|==== uplink data starts flowing =========================>|Major Phases
| Phase | What happens |
|---|---|
| 1. Uplink trigger | A UE application, transport keepalive, or user action creates data that cannot be sent until the UE regains active service. |
| 2. Access restoration | The UE uses resume when context is still available or falls back to a fresh RRC setup if needed. |
| 3. NAS service request | The UE asks the AMF to restore active service using the stored registration and security context. |
| 4. Session and bearer confirmation | The network confirms that the required PDU-session context is still usable for uplink traffic. |
| 5. Data transfer resumes | The AMF accepts the request and the gNB or UPF path becomes active for actual user-plane packets. |
Step-by-Step Breakdown
UE detects a need to send data
Sender -> receiver: UE internal application -> UE signaling stack
Message(s): Application data trigger or uplink packet pending
Purpose: Start the control path needed to move from passive reachability to active service.
State or context change: The UE decides that existing registered context is not enough and active transfer must be restored.
Note: This is the clean mobile-originated branch of the broader service request family, so do not confuse it with paging-driven restoration.
UE restores the radio signaling path
Sender -> receiver: UE -> gNB
Message(s): RRC Resume path or fresh RRC setup sequence
Purpose: Rebuild enough access state to deliver the NAS request to the AMF.
State or context change: The UE regains a control-plane channel through the serving gNB.
Note: If the UE uses fresh setup instead of resume, the mobile-originated data goal is still the same, but the trace reveals that previous RRC context was not reusable.
UE sends Service Request
Sender -> receiver: UE -> gNB -> AMF
Message(s): Service Request
Purpose: Ask the core to restore active service for uplink traffic using the existing registration.
State or context change: The AMF evaluates whether the stored security and registration context remain valid.
Note: Inspect the service type and PDU Session Status carefully because this is where the uplink intent becomes explicit.
Network validates and restores service context
Sender -> receiver: AMF <-> gNB and optionally AMF <-> SMF
Message(s): Context resume or setup handling plus possible session checks
Purpose: Confirm that the UE can move back into active service and the right session can carry uplink packets.
State or context change: The access path and service state become active enough for packet transfer.
Note: A good NAS result with no traffic often means the session or N3 path was not fully reinstated after the AMF accepted service.
Service Accept and uplink traffic release
Sender -> receiver: AMF -> UE and UE -> UPF through gNB
Message(s): Service Accept and resumed data flow
Purpose: Finalize the service restoration and allow the UE to send the waiting uplink data.
State or context change: The UE becomes active and the uplink path is usable again.
Note: Correlate the first real user-plane packet with Service Accept to confirm the procedure finished functionally, not just logically.
Important Messages in This Flow
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| RRC Resume sequence | RRC | UE <-> gNB | Restores the signaling context quickly when the UE already has resumable radio state. | Check whether resume succeeded or whether the network fell back to fresh setup. |
| Service Request | NAS | UE -> AMF | Requests active service so mobile-originated data can be sent. | Inspect service type, PDU Session Status, and security-context continuity. |
| Service Accept | NAS | AMF -> UE | Confirms that active service is restored for the UE. | Verify that it is followed by actual uplink packets on the expected session path. |
| Service Reject | NAS | AMF -> UE | Rejects the attempt to restore active service with the stored context. | Use the cause to decide whether re-registration or session repair is needed. |
Important Parameters to Inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| Service type | The reason active service is being requested. | Service Request | Shows that the branch is mobile-originated data rather than paging response. | Wrong value can cause unexpected network behavior. |
| PDU Session Status | UE view of which sessions are active or resumable. | Service Request | Helps explain which session should carry the new uplink data. | Mismatch with network-side session state. |
| Allowed NSSAI / access policy context | Slice or policy context that still applies to the resumed service. | Registration and service context | Useful when uplink works only on some sessions or slices. | Policy drift after mobility or subscription changes. |
| User-plane tunnel context | Mapping between gNB and UPF for the resumed traffic. | N3 and N4 coordination | Confirms that actual packets can move after NAS success. | Tunnel missing or stale despite successful Service Accept. |
| Security context reference | The NAS protection context used to continue with existing registration. | Service Request and validation path | Explains whether the UE can reuse its old secure context cleanly. | Expired or mismatched context can turn a simple data trigger into full re-registration. |
Success Criteria
- The UE restores control-plane signaling successfully.
- Service Request is accepted with the existing registration context.
- The user-plane path and required session mapping are active again.
- The waiting mobile-originated packets are delivered successfully.
Common Failures and Troubleshooting
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| UE reaches RRC but Service Request never appears | The access restoration succeeded only partially or NAS delivery was blocked. | RRC completion, NAS container transport, and gNB relay behavior. | RRC Resume or Setup | NR-Uu, N2 | Separate access success from NAS delivery success. They do not always fail together. |
| Service Request is rejected | The old registration, security, or policy context is no longer valid for active service. | Reject cause, service type, and recent mobility or policy changes. | Service Request, Service Reject | N1, N2 | This usually means broader recovery is needed, not just another uplink retry. |
| Service Accept arrives but no uplink traffic passes | The user-plane path or PDU-session mapping did not reactivate correctly. | N3 tunnel state, gNB data path, and session continuity details. | Service Accept | N3, N4, N11 | Treat this as post-NAS reactivation failure rather than a pure NAS fault. |
| UE falls back to registration | Stored service context was not trustworthy enough to resume active service. | Whether Registration Request follows the failed service branch. | Service Reject, Registration Request | N1, N2 | The fallback is a clue that the original registration state was effectively lost. |
What to Check in Logs and Traces
- Check that the trigger is truly mobile-originated uplink data and not paging-driven restoration.
- Verify whether the UE used RRC Resume or fell back to fresh setup, because that changes the trace interpretation.
- Inspect Service Request for the expected service type and PDU Session Status.
- Correlate Service Accept with the first real uplink user-plane packets.
- If NAS looks clean but traffic stalls, inspect N3 or session-side mapping before treating it as an application failure.
Related Pages
Related sub-procedures
Related message reference pages
Related troubleshooting pages
Notes
This page is the UE-originated branch of Service Request. The clean mental model is uplink trigger first, then access restoration, then NAS acceptance, then proof that real packets left the UE.
FAQ
What is UE-initiated connection for mobile-originated data?
It is the service-restoration path used when the UE wants to send uplink data while it is not currently in active service state.
How is it related to Service Request?
It is a practical mobile-originated branch of the broader 5G Service Request procedure.
Does paging happen first here?
Usually no. The trigger starts inside the UE because it has new uplink traffic to send.
What confirms success?
The UE receives Service Accept and actual uplink packets begin flowing on the expected PDU session.
What should I inspect first?
Start with whether the UE restored RRC correctly, then inspect Service Request fields, the NAS result, and finally the N3 user-plane path.