Service Request Call Flow (Idle → Connected) in 5G NR

Introduction

The Service Request is the most frequently run signalling procedure in a live 5G network — far more common than registration, which typically happens once per power cycle or per new tracking area. Every time a registered-but-idle phone gets a notification, sends a keep-alive, or the user unlocks it to load a page, a Service Request is what rebuilds the radio bearers and the user-plane tunnel that idle mode tore down.

It sits at the boundary between the connection-management states: it moves the UE from CM-IDLE to CM-CONNECTED on the core side, and from RRC_IDLE/RRC_INACTIVE to RRC_CONNECTED on the access side. It exists in three flavours — UE-triggered, network-triggered (paging first), and the lighter control-plane variant — but all three end in the same place: re-activated PDU session user planes and a restored N3 tunnel.

Because it stitches together paging, RRC, NGAP over N2, NAS 5GMM, and the SMF/UPF re-activation over N11/N4, a Service Request failure is almost always localisable to one hop. This page walks the heaviest path — network-triggered from RRC_IDLE — message by message, then shows what the RRC_INACTIVE resume path skips.

Call Flow — Network-Triggered Service Request from RRC_IDLE

Read the flow as four beats. First, downlink data arrives and the core decides it must fetch the UE. Second, the UE is paged and answers with an RRC setup that carries the NAS Service Request. Third, the AMF re-activates the user plane toward the SMF and orders the gNB to build the security context and radio bearers. Fourth, the N3 tunnel is restored and user data flows again.

A few things are worth noticing. The NAS Service Request is piggybacked in step 4 on RRCSetupComplete and then relayed transparently by the gNB in the NGAP INITIAL UE MESSAGE at step 5 — the gNB does not interpret it. Step 6 is where the SMF is told to re-activate the user plane; it allocates the UPF-side N3 tunnel endpoint and returns it so the AMF can pass it to the gNB inside the Initial Context Setup Request at step 7, which also carries the security context and the PDU session resource setup list. Steps 8–9 build the data radio bearers over the air. Only after step 10 confirms the gNB-side tunnel endpoint to the AMF (relayed on to the SMF) is the bidirectional N3 path complete and the buffered downlink packets released.

Message-by-message breakdown

The same discipline that works for RACH works here: identify the first message that did not happen and you have localised the fault. Below, each key step of the network-triggered flow gets its own debugging checklist and the failure modes that live at that hop.

Step 1 — Paging

DL data buffered at the UPF makes the SMF send Namf_Communication_N1N2MessageTransfer to the AMF; the AMF pages the UE across its whole registration area (every TAI in the TAI list). The UE monitors its paging occasion and matches its 5G-S-TMSI.

Steps 2–4 — RRC setup carrying the NAS Service Request

The paged UE runs RACH and RRC: RRCSetupRequest (Msg3, with ng-5G-S-TMSI as identity and an establishmentCause such as mt-Access), RRCSetup (Msg4), and RRCSetupComplete carrying the NAS Service Request as dedicatedNAS-Message.

Steps 5–6 — NGAP relay and SMF user-plane re-activation

The gNB relays the Service Request transparently in the NGAP INITIAL UE MESSAGE; the AMF calls Nsmf_PDUSession_UpdateSMContext so the SMF re-activates the user plane and allocates the UPF-side N3 tunnel endpoint (TEID).

Steps 7–10 — Initial Context Setup, DRB, and N3 completion

The AMF sends Initial Context Setup Request over N2 with the security context and the PDU session resource setup list (QoS flows + UPF N3 TEID). The gNB runs RRCReconfiguration to rebuild the DRBs, the UE confirms with RRCReconfigurationComplete, and the gNB returns Initial Context Setup Response with its own N3 TEID — completing the bidirectional tunnel and releasing buffered DL data.

Representative core/NGAP trace (network-triggered Service Request) — illustrative, values vary by vendor/build:

Why a Service Request Exists

When a UE goes idle, two independent state machines drop to their resting positions. On the access side RRC moves to RRC_IDLE (or the intermediate RRC_INACTIVE); the gNB releases the radio bearers and, in RRC_IDLE, discards the UE's access-stratum context entirely. On the core side the NAS connection-management state moves to CM-IDLE: there is no N2 signalling association and no N3 user-plane tunnel between the gNB and the UPF. The UE stays RM-REGISTERED — the AMF still holds its mobility context and can page it — but the pipe that carries actual traffic is gone.

UE-Triggered, Network-Triggered, and the Control-Plane Variant

The same NAS message serves three situations that differ only in what starts the ball rolling.

• UE-triggered. The UE has uplink user data to send, or a NAS/RRC signalling need (for example a mobility registration update where it also wants the user plane back). It simply initiates RRC and sends Service Request. No paging is involved — the UE already knows it wants a connection.
• Network-triggered. Downlink data (or downlink signalling) arrives for an idle UE. The UPF buffers the packets and notifies the SMF; the SMF sends an Namf_Communication_N1N2MessageTransfer to the AMF, which cannot reach the UE directly, so it pages the UE across its registration area. The paged UE then responds by launching exactly the same UE-side Service Request. In other words, network-triggered = "page first, then the UE does a Service Request."
• Control-Plane Service Request. A lighter variant used mainly with the Control Plane CIoT 5GS optimisation, where small data and SMS are carried inside NAS on the signalling plane rather than over a re-activated N3 user-plane tunnel. The UE sends a Control Plane Service Request and the payload rides the control plane, avoiding the cost of full DRB and N3 setup for tiny, infrequent transfers.

RRC_IDLE vs RRC_INACTIVE — Two Speeds of Resume

The cost of a Service Request depends heavily on which idle-ish state the UE was in. From true RRC_IDLE the gNB has no stored access-stratum context, so the UE must run a full RRC setup and the NAS Service Request travels all the way to the AMF. From RRC_INACTIVE the last serving gNB kept the UE's AS context and the core-network connection was only "suspended" — so the UE can resume with a much lighter RRCResume handshake and, in the best case, never bother the AMF at all.

The rest of this page walks the heavier case — network-triggered Service Request from RRC_IDLE — because it exercises every node. The resume path section then shows what is skipped when the UE was merely RRC_INACTIVE. Both states, and the transitions between them, are covered in RRC states.

The RRC_INACTIVE Resume Path — Why It's Faster

When the UE was suspended into RRC_INACTIVE rather than released to RRC_IDLE, the previous ("last serving") gNB kept the full access-stratum context and gave the UE an I-RNTI — a handle that identifies that stored context. On the core side, the N2 and N3 connections were placed into a suspended state, not torn down. Resuming is therefore a much lighter transaction.

The UE sends RRCResumeRequest carrying its I-RNTI and a short security token. If it lands on the same gNB, that gNB simply reactivates the stored context. If it lands on a different gNB, the new gNB reads the I-RNTI, works out which old gNB holds the context, and fetches it over the Xn interface with a Retrieve UE Context Request / Retrieve UE Context Response exchange — no full RRC rebuild, no round-trip to the AMF to re-derive keys from scratch. The gNB replies with RRCResume (which itself carries the radio-bearer reconfiguration), and the UE confirms with RRCResumeComplete. The user plane is re-activated by the network resuming the suspended N3 path.

The trade-off is that the last serving gNB must retain context and the core must hold suspended associations, so RRC_INACTIVE is a resource choice the network makes; a UE parked there too long, or roaming beyond the configured RAN notification area, may still fall back to a full RRC_IDLE Service Request.

Summary

The Service Request is the everyday hinge in and out of connected mode, and it fails in predictable places. Debug it as a chain: if the UE never wakes, suspect paging — coverage, DRX alignment, wrong 5G-S-TMSI, or a stale TAI list. If it wakes but never reaches the AMF, suspect RACH/RRC — the four-step procedure or a missing NAS Service Request in RRCSetupComplete. If the AMF gets it but the pipe never rebuilds, suspect the SMF/UPF re-activation (Nsmf_PDUSession_UpdateSMContext, N4) or the Initial Context Setup/DRB rebuild and N3 TEID exchange.

Two facts save the most time. First, the message is always sent by the UE — "network-triggered" just means "paged first," so a network-triggered failure is often really a paging or RACH failure. Second, the user plane is not up until both N3 TEIDs are exchanged; a session that looks "set up" but drops downlink almost always has a one-sided or mismatched tunnel endpoint. And remember the fast path: from RRC_INACTIVE most of this is skipped via RRCResume and Xn, so confirm which state the UE was actually in before assuming the heavy flow.

Quick Q&A