Service request — Going from idle to connected, from either end

5G Systems Notes · Concept map · Service request Route · Hierarchy · Index · All concepts · Hub

The device — identity, state, mobility

Where it sits

Sits atLevel 12 of the hierarchy · The device — identity, state, mobility · explained
Learn firstCM state — 17 concepts in the full chain, see the paths
UnlocksNothing else depends on it directly.
Primary clauseTS 24.501 §5.6.1, TS 23.502 §4.2.3.2
Used inref-ue-state 7 · index 1 · ref-ue-identity 1 · ref-ue-mobility 1
Scanned from the notes at page load and joined with terms.json; nothing on this card is typed by hand.

What it is

What it is. The procedure that takes a device from CM-IDLE to CM-CONNECTED. TS 24.501 §5.6.1, TS 23.502 §4.2.3.2. It is used in both directions, and that symmetry is the interesting part.

The device has something to send. TS 23.501 §5.3.3.2.2: it shall "perform a Service Request procedure when the UE has uplink signalling or user data to be sent".

The network has something for the device. The device is paged, and it shall "respond to paging by performing a Service Request procedure".

One procedure, both causes. The network cannot send anything to an idle device — there is no N3 tunnel to send it down — so it cannot deliver; it can only ask the device to come and get it. The device then runs exactly the procedure it would have run had it initiated. Downlink delivery is uplink establishment with a wake-up call in front of it.

What it re-establishes:

the AN signalling connection (RRC) · the N2 connection between the base station and the AMF · the N3 tunnels for whichever PDU sessions are to be activated · the access-stratum security context.

Not every session is reactivated. The device names which PDU sessions it wants active. A device with three sessions that only needs one does not pay to restore the other two — the sessions still exist in the core the whole time; what is torn down and rebuilt is the user-plane path for them.

That distinction is the whole economy of idle mode. A PDU session is core-network state: an address, an anchor, a set of rules, and it survives hours of idleness costing nothing but memory. The expensive parts — a radio connection and an N3 tunnel — exist only while there is traffic. Your phone keeps its IP address all day and holds a radio connection for seconds at a time.

The full sequence, downlink. A packet arrives at the UPF, which buffers it and raises a Downlink Data Notification to the SMF (TS 23.501 §6.2.2); the SMF tells the AMF; the AMF pages; the device runs Service Request; the tunnels come up; the buffered packet is delivered. That is what happens between a message being sent to you and your phone buzzing.

Read on

This concept is read as part of one argument in ref-ue-state, alongside the rest of its group.

Widget not found: sim_status

Before this concept, the hierarchy says to learn the following — the full chain, in order:

To understand Service request (level 12) you first need 17 other concepts. Read them in this order — everything on one line can be read in any order, but no line before the one above it:
Immediately before Service request: CM state.
Keep going — where this sits on the route
Nothing depends on this one directly
It is a leaf of the graph — follow the route rather than the branch.
The route is every concept in the folder ordered by level, so nothing here needs anything after it. Computed at page load from terms.json; the same numbering as the route page.
5G Systems Notes · Concept map · Service request Top · Concept map · Hub