3GLTEInfo Text-based logo for the 3GLTEInfo telecom engineering reference platform. 3GLTE INFO TELECOM ENGINEERING REFERENCE

Telecom engineering reference for protocols, messages, call flows, troubleshooting, releases, and tools.

Menu

Home / Call Flows / 5G / Mobile-Terminated Data / Paging-to-Service Recovery

5G Mobile-Terminated Data / Paging-to-Service Recovery Call Flow

call-flow 5G NR | 5GC | Paging | RRC | NAS | Downlink Service Recovery

5G mobile-terminated data recovery is the downlink-driven call flow where the network has data for a UE and must page it back into active service.

It joins paging, RRC restoration, NAS Service Request, and downlink user-plane reactivation into one practical reachability sequence.

Introduction

This is the cleanest end-to-end story for the phrase paging to service recovery in 5G.

The network already has something to deliver, but the UE is only reachable through paging. The key analysis task is to follow the chain all the way from paging to actual data arrival instead of stopping at the first successful NAS message.

What Is Mobile-Terminated Data / Paging-to-Service Recovery in Simple Terms?

  • What starts the procedure: Pending downlink data arrives for a registered but inactive UE.
  • What the UE and network want to achieve: Make the UE reachable again and restore active service so the downlink packets can be delivered.
  • What success looks like: Paging reaches the UE, Service Request succeeds, and downlink traffic resumes.
  • What failure means: The network cannot reach the UE, the service request fails, or the user-plane path remains blocked after restoration.

Why this procedure matters

Many field problems look like a simple paging issue when the real break happens later in service restoration or in the revived user plane. This page helps keep the whole MT-data chain visible from first page to actual packet delivery.

Quick Fact Sheet

Procedure name 5G Mobile-Terminated Data / Paging-to-Service Recovery
Domain 5G NR + 5GC network-triggered service restoration
Main trigger Downlink data arrives for a UE that is registered but not in active service state
Start state UE is registered and reachable through paging, but not currently carrying active user traffic
End state UE answers paging, restores service, and the downlink data path becomes usable
Main nodes UE, gNB, AMF, SMF, UPF
Main protocols RRC, NAS, NGAP, PFCP, downlink user-plane reactivation
Main success outcome Paging reaches the UE, Service Request succeeds, and the downlink packets are delivered
Main failure outcome Paging loops, Service Request fails, or user-plane restoration stalls after access recovery
Most important messages Paging, RRC Resume or Setup, Service Request, Service Accept
Main specs TS 23.502, TS 24.501, TS 38.300, TS 38.331, TS 29.244
5G mobile-terminated data and paging-to-service recovery call flow
Sponsored Advertisement

Preconditions

  • The UE is already registered in the 5GS.
  • The network has pending downlink data for the UE.
  • The access side still knows enough reachability context to page the UE.
  • Stored security and registration context are valid enough to support service restoration.

Nodes and Interfaces

Nodes involved

Node Role in this procedure
UE Receives paging, restores access signaling, sends Service Request, and becomes ready for downlink delivery.
gNB Broadcasts or routes paging toward the UE, restores signaling context, and forwards the resumed traffic toward the radio side.
AMF Controls paging, validates the UE service restoration request, and coordinates access-side context handling.
SMF Ensures the session-side context still supports the pending downlink delivery.
UPF Buffers or resumes downlink forwarding once the N3 path is active again.

Interfaces used

Interface Path Role
NR-Uu UE <-> gNB Carries paging reception, paging response behavior, and RRC restoration.
N1 UE <-> AMF Carries Service Request and Service Accept.
N2 gNB <-> AMF Carries paging control, UE context handling, and access restoration signaling.
N11 AMF <-> SMF Used when the pending downlink data path needs confirmation or refresh.
N3 / N4 gNB <-> UPF and SMF <-> UPF Restore the path needed to forward the waiting downlink packets.

End-to-End Call Flow

UE                gNB                AMF                SMF / UPF
|                  |                  |                    |
|<----- Paging ----|                  |                    |
|-- RRC Resume/Setup ---------------->|                    |
|-- Service Request ----------------->|                    |
|                  |                  |-- session checks ->|
|                  |                  |<-- session ready ---|
|<-- Service Accept ------------------|                    |
|<==== pending downlink packets delivered =================|

Major Phases

Phase What happens
1. Downlink data trigger The network receives data for a UE that is not currently in active service state.
2. Paging The AMF and access side page the UE so it can rebuild enough access state to receive service again.
3. Access restoration and NAS request The UE resumes or rebuilds RRC and sends Service Request to restore active service.
4. Context reactivation The network validates the stored context and reactivates the user-plane path.
5. Downlink data delivery The UE receives Service Accept and the pending packets are delivered through the restored path.

Step-by-Step Breakdown

Network receives downlink data for an inactive UE

Sender -> receiver: Data source -> UPF / core service path

Message(s): Pending downlink traffic indication

Purpose: Trigger a reachability workflow because the UE is not in active service state.

State or context change: The network knows data is waiting but cannot yet deliver it over the current access state.

Note: This is the distinguishing feature from mobile-originated data: the trigger starts from the network side, not the UE side.

AMF pages the UE

Sender -> receiver: AMF -> gNB -> UE

Message(s): Paging

Purpose: Make the UE respond and rebuild the signaling path required for service recovery.

State or context change: The UE moves from passive reachability into an active response branch.

Note: If paging repeats before any NAS activity, focus on TAC, cell selection, and paging distribution first.

UE restores RRC and requests service

Sender -> receiver: UE -> gNB -> AMF

Message(s): RRC Resume or fresh setup plus Service Request

Purpose: Restore enough access and core-side context to receive the pending downlink packets.

State or context change: The AMF can now evaluate the existing registration and security context for active service restoration.

Note: A paging response without a later Service Request usually means the access leg came back only partially.

Network reactivates service context

Sender -> receiver: AMF <-> gNB and optionally AMF <-> SMF

Message(s): UE context handling and session-side confirmation

Purpose: Prepare the network so the downlink packets can move to the UE again.

State or context change: The service state becomes active and the N3 path is ready to forward data.

Note: If the NAS outcome looks clean but user traffic still waits in the core, inspect user-plane reactivation rather than paging.

Service Accept and downlink delivery

Sender -> receiver: AMF -> UE and UPF -> UE through gNB

Message(s): Service Accept and resumed downlink data

Purpose: Complete the recovery so the waiting data reaches the UE.

State or context change: The UE is active and the previously blocked downlink path is usable.

Note: The first real downlink packets are part of the success proof; do not stop analysis at Service Accept alone.

Important Messages in This Flow

Message Protocol Direction Purpose in this procedure What to inspect briefly
Paging RRC Network -> UE Notifies the UE that the network has pending data or other service to restore. Check cause, TAC coverage, cell timing, and whether the UE actually responded.
Service Request NAS UE -> AMF Allows the UE to convert paging response into real active service restoration. Inspect service type and the session context implied by the pending downlink data.
Service Accept NAS AMF -> UE Confirms that service restoration succeeded. Verify that waiting downlink packets follow immediately after success.
Service Reject NAS AMF -> UE Stops the recovery when stored context cannot support active service. Use the cause to decide whether the UE should re-register or retry later.

Important Parameters to Inspect

Parameter What it is Where it appears Why it matters Common issues
Paging cause and context Reason the network paged the UE. Paging Helps distinguish MT data from voice or mobility-related reachability events. Wrong interpretation sends you to the wrong call-flow family.
Service type Indicates the service restoration reason once the UE responds. Service Request Confirms the NAS branch taken after paging. Unexpected type can suggest a UE implementation or context mismatch.
PDU Session Status UE view of active or resumable sessions. Service Request Useful when only some downlink sessions recover. Mismatch with buffered network-side session expectations.
Paging area / TAC The area where the network tried to reach the UE. Paging and N2 context Explains why the UE was or was not found during recovery. Wrong TAC or stale reachability registration.
User-plane reactivation state Status of the data path after service acceptance. N3 / N4 and session handling Proves whether data delivery is possible beyond NAS success. Clean NAS but blocked downlink forwarding.

Success Criteria

  • Paging reaches the UE and triggers a valid response path.
  • The UE restores RRC and sends Service Request successfully.
  • The network reactivates access and session context cleanly.
  • The waiting downlink packets are delivered on the restored path.

Common Failures and Troubleshooting

Symptom Likely cause Where to inspect Relevant message(s) Relevant interface(s) Likely next step
Paging repeats with no response The UE did not detect or answer paging, or the network paged the wrong place. Paging distribution, TAC, DRX timing, and radio availability. Paging NR-Uu, N2 Fix reachability first because NAS service restoration cannot start without it.
UE answers access but Service Request never completes The access recovery path came back but the NAS or security context was not usable. RRC completion, NAS protection, and Service Request delivery. Service Request NR-Uu, N1, N2 This is a partial recovery, not a full success.
Service Accept arrives but downlink data still does not flow The N3 or session-side path did not reactivate cleanly. UPF buffering, N3 tunnel state, and session continuity indicators. Service Accept N3, N4, N11 Treat it as a post-restoration user-plane issue.
UE falls back to registration after paging Stored context was too stale for service recovery. Registration Request after failed service path. Service Reject, Registration Request N1, N2 This indicates context loss rather than a pure paging problem.

What to Check in Logs and Traces

  • Start with paging reachability: TAC coverage, UE availability, and whether the page was actually answered.
  • Verify whether the UE restored RRC fully enough to send Service Request.
  • Inspect the service type and session context carried after the page response.
  • Correlate Service Accept with the first real downlink packets reaching the UE.
  • If NAS succeeds but delivery does not, inspect buffered traffic, N3 state, and UPF reactivation rather than stopping at the paging analysis.

Related Pages

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

Paging success does not equal service success. The real end of this workflow is successful data delivery after the service-restoration branch completes.

Sponsored Advertisement

FAQ

What is mobile-terminated data paging-to-service recovery?

It is the network-triggered workflow that pages a registered UE and restores active service so pending downlink data can be delivered.

How is it different from mobile-originated data restoration?

The trigger comes from pending downlink traffic in the network rather than from a new uplink packet in the UE.

Does paging alone mean success?

No. Paging only starts the recovery. Success requires service restoration and real data delivery afterward.

What message usually appears after paging response?

The UE typically restores RRC and then sends Service Request so the AMF can activate service again.

What should I inspect first in a failing trace?

Start with paging reachability, then confirm RRC restoration, Service Request or Service Accept, and finally the resumed downlink user plane.