Paging and Service Resume Troubleshooting
Paging and service resume problems are easy to misclassify. In some cases the AMF never starts paging. In others the NG-RAN pages correctly but the UE does not monitor or respond. In still others the UE responds, but service resume fails later during RRC resume, NAS Service Request, or user-plane reactivation.
This page is written as a fault-isolation guide. It follows the real procedure chain from idle or inactive state through paging, RRC response, NAS Service Request, and resumed data delivery. It also includes call flows to separate “not paged,” “paged but no response,” “response but failed resume,” and “resume succeeded but no traffic” scenarios.
Paging and Resume Failure Ladder
Start by deciding whether the first real break is in paging generation, paging reception, resume, Service Request, or post-resume service restoration across N2, N3, and the access-side path.
Step 1: UE becomes idle or inactive
- AN release due to UE inactivity or other release reasons
- UE camps on a suitable cell
- UE monitors paging while camped normally
Step 2: Network decides to page
- AMF detects pending NAS signalling or user data
- Network Triggered Service Request context starts
- AMF sends NGAP Paging and starts paging supervision
Step 3: NG-RAN pages the UE
- paging cause may be included
- eDRX or paging-time-window information may be included
- correct paging area, tracking area, and cell coverage matter
Step 4: UE responds
- from idle, the UE typically initiates access and the Service Request path
- from inactive, the UE may use the RRC resume path first
- response must match stored UE context and access conditions
Step 5: Service resumes
- UE Triggered Service Request progresses
- N2, N3, or access-side resources are reactivated
- downlink NAS signalling or user-plane data is delivered
Symptoms and Fast Triage
Use the visible symptom first, then decide whether you are still in paging or already in resume and service-restoration failure handling.
Downlink data is pending but no UE response is ever seen
- AMF never started paging
- NGAP Paging not delivered correctly
- paging area or TAC mismatch
- UE not monitoring paging on the expected cell
UE sees or logs paging but service does not resume
- RRC resume or RRC access failure
- Service Request not sent or not accepted
- resume identity or context mismatch
- lower-layer failure before Service Request completion
Service Request starts but ends in reject or abort
- T3447 or T3448 related behavior
- Service Reject cause analysis
- TAI or registration-context issue
- lower-layer release before completion
Resume appears successful but traffic still does not flow
- N3 or user-plane reactivation failure
- allowed PDU session reactivation mismatch
- one or more sessions not re-activated
- QoS, tunnel, or UPF problem after resume
Call Flows
Read these flows in order: normal success, no UE response, inactive resume failure, Service Request failure, and resume-without-traffic restoration failure.
Paging and normal service resume
Paging sent, UE never responds
Paging received but inactive resume fails
Paging succeeds but Service Request fails
Resume succeeds but traffic still fails
Network Triggered Paging Checks
Treat paging initiation as its own branch first. If the AMF never starts paging, there is no point yet in decoding RRCResumeRequest or Service Request behavior.
The paging side starts when pending NAS signalling or user data exists for a UE in the idle service context. If paging supervision such as T3513 expires with no response, the first question is whether the UE was ever reachable through the intended paging area and cell coverage.
- was downlink data or NAS signalling actually pending
- did the AMF issue NGAP Paging
- did paging supervision expire with no UE response
- was paging restricted by policy or state
- did paging target the correct access type and area
What this branch really means
A missing UE response after paging does not automatically mean a radio broadcast failure. It can also mean the UE was camped on the wrong area, not monitoring the expected occasion, or unable to begin access or resume even after the page was received.
Idle-Mode and Inactive-Mode Response Checks
Treat RRC_IDLE and RRC_INACTIVE as different troubleshooting branches, because the UE response path can diverge early.
Idle-mode response path
From idle, the UE typically moves into access and then the Service Request path when paged for 5GS services. If that never starts, the fault may still be paging reception, access initiation, or early lower-layer setup.
Inactive-mode response path
In inactive mode, the UE may first send RRCResumeRequest. That means the investigation must check resumeIdentity, resumeMAC-I, resumeCause, and stored context validity before assuming the problem is only NAS-side service resumption.
Paging Broadcast and Area Checks
Correct camping, suitable-cell behavior, and area alignment are foundational checks before blaming the AMF or NAS side.
A camped UE in idle or inactive mode monitors paging according to SIB1-based assumptions. That makes cell selection, TAC or TAI alignment, and paging occasion calculation part of the first troubleshooting layer, not optional background checks.
- serving cell and TAC or TAI alignment
- UE camping state and suitable-cell status
- SIB1-based paging monitoring assumptions
- Paging Cause or NR Paging eDRX Information handling
- paging-time-window interpretation in the NG-RAN
Service Request Failure After Paging Response
Once the UE responds, the issue is no longer pure paging. At that point the investigation shifts into Service Request success, rejection, or abort behavior.
- did the UE actually send Service Request
- did lower layers fail before completion
- was Service Reject received
- was T3447 or T3448 already running
- did the current TAI force the UE to abort and re-register instead
Why this matters
If the UE has already reacted to paging and started Service Request, then paging worked. The fault is now in lower-layer continuation, NAS rejection, timer-driven restriction, or state inconsistency during service resumption.
Service Reject and Back-Off Checks
When the UE receives Service Reject, decode that branch before assuming the problem is still in paging or RRC resume.
Resume Success but No User-Plane Service
Do not stop the investigation just because the UE became reachable again. Reachability restoration and service restoration are not the same thing.
This branch covers the cases where paging succeeded and the UE resumed service context, but the actual PDU sessions, N3 path, QoS handling, or UPF-side continuity still did not come back cleanly.
- whether the resumed UE included the right PDU sessions for reactivation
- whether the AMF or SMF reactivated the expected user-plane resources
- whether one service resumed while another remained inactive
- whether the paging was for signalling only or for pending user data
- whether the failure is actually N3, tunnel, or UPF related after successful resume
Practical Troubleshooting Workflow
Anchor the investigation in the first hard break, then align the same attempt across paging, RRC, NAS, and user-plane restoration.
1. Confirm the first hard break
- no paging initiated by the AMF
- paging initiated but the UE never responds
- UE responds but resume or access fails
- Service Request fails
- resume succeeds but service is still missing
2. Correlate the same attempt across layers
- AMF paging decision and timer behavior
- NGAP Paging transmission
- radio paging monitoring on the serving cell
- RRC access or resume attempt
- NAS Service Request and any Service Reject
- user-plane reactivation outcome
3. Separate paging failure from resume failure
- paging failure means the UE was never successfully reached
- resume failure means the UE responded but did not restore signalling or user plane
- post-resume failure means service stayed broken after reachability was restored
4. Validate area, context, and timers
- TAC, TAI, and paging area correctness
- camping state and suitable-cell status
- stored inactive context validity
- T3513, T3517, T3447, and T3448 behavior
- PDU session reactivation scope
Evidence Checklist for Escalation
Package core, RAN, and UE evidence around the same paging attempt so the fault can be separated cleanly across teams.
Minimum core evidence
- AMF trigger reason for paging
- NGAP Paging record
- paging timer outcome
- Service Request or Service Reject record
- PDU-session reactivation result if relevant
Minimum RAN evidence
- paging transmission confirmation
- serving cell, TAC, and area alignment
- RRCResumeRequest result or access attempt result
- any resume-context validation failure
- later release or fallback behavior
Minimum UE-side evidence
- idle or inactive state before paging
- paging indication seen or not seen
- access or resume response attempt
- Service Request or reject handling
- whether traffic resumed after the response
Minimum identifiers
- SUPI or 5G-GUTI if available
- TAC, TAI, and cell identity
- AMF identity
- resume identity or context key references if available
- affected PDU Session IDs for traffic-resume issues
Specification Map
Use these reference anchors when you need to verify whether the break is in camping and paging monitoring, NAS service resumption, N2 paging content, or the RRC response path.
TS 38.304: idle and inactive camping and paging monitoring behaviorTS 24.501: paging procedure, Service Request, Service Reject, and timer behaviorTS 23.502: Network Triggered Service Request and service reactivation contextTS 38.413: NGAP Paging and paging-related informationTS 38.331: RRC resume request fields and radio response context
FAQ
Why does the network have pending downlink data but the UE never resumes service?
The break can be before the UE ever reacts. Check whether the AMF actually started paging, whether NGAP Paging was sent to the correct area, whether the UE was camped on a suitable cell and monitoring paging, and whether paging supervision such as T3513 expired with no response.
How do I distinguish “UE was never paged” from “UE was paged but failed to resume”?
Use the first hard checkpoint. If no radio paging or UE reaction exists, the fault is still in paging generation, targeting, or monitoring. If the UE begins access, RRC resume, or Service Request, paging already worked and the failure moved into resume or service restoration.
What should I check when the UE is in RRC_INACTIVE instead of RRC_IDLE?
Treat it as a separate branch. Inactive-mode troubleshooting should inspect RRCResumeRequest, resumeIdentity, resumeMAC-I, resumeCause, stored context validity, and any resume-specific rejection before assuming the problem is pure NAS service resumption.
When does paging succeed but Service Request still fail?
That happens when the UE became reachable and started the resume path, but the NAS Service Request was rejected, aborted by lower-layer failure, blocked by back-off behavior, or interrupted by a context or TAI inconsistency.
Why can resume succeed while traffic is still unavailable?
Because reachability restoration is not the same as service restoration. After the UE responds, the expected PDU sessions and user-plane resources still need to be reactivated correctly. A session-reactivation, QoS, tunnel, or UPF issue can keep traffic broken after paging itself already succeeded.
Which timers matter most in paging and service resume troubleshooting?
Start with T3513 for paging supervision, T3517 for Service Request supervision, and T3447 or T3448 when back-off or control-plane restrictions may change UE behavior. Those timers help explain why paging or resume appears inconsistent across attempts.