PDU Session Management (5GSM) in 5G NR

Introduction

A PDU session is the object that turns a registered-but-idle UE into one that can actually move user data. It is a 5GSM (session-management) procedure between the UE and the SMF, and it is what maps the UE's traffic onto a slice, a data network, an IP (or Ethernet) address, a set of QoS treatments, and a user-plane path anchored at a UPF.

It sits immediately after registration in the UE lifecycle: registration authenticates the subscriber and activates NAS security, then a PDU session establishment gives that subscriber a data pipe. The same machinery runs again for modification (adding a voice flow to a data session), release (tearing it down), and user-plane re-activation (bringing an idle session's radio bearers back with a Service Request).

Establishment touches three planes at once — NAS/5GSM signalling, the N4/PFCP provisioning of the UPF, and the NGAP resource setup that builds radio bearers — so a "no data" fault can live in any of them. Walking the procedure message by message, plane by plane, is what turns "internet doesn't work" into a precise diagnosis: NAS accept missing? UPF not programmed? DRB not set up? This page follows that thread.

Why a PDU session is needed

Mobility registration carries no user data by itself. Something has to bind the UE's traffic to a slice (which tenant/service), a DNN (which network to reach), a set of QoS treatments (how each flow is handled), a user-plane anchor (where packets exit to the data network), and an address (how the UE is reachable). The PDU session is exactly that binding — and because it is a first-class, independently addressable object, one registered UE can hold several at once, on different slices and UPFs, without them interfering.

What a PDU Session Is

A PDU session is an end-to-end user-plane association between the UE and a single data network, identified by a PDU Session ID the UE itself chooses (values 1–15). It has a type (IPv4, IPv6, IPv4v6, Ethernet or Unstructured), belongs to exactly one slice (S-NSSAI), and terminates on one data network name (DNN). It bundles one or more QoS flows and is anchored on a UPF (the PDU Session Anchor). A UE can hold several sessions concurrently — one to internet for data and one to ims for voice is the classic pairing — each independently addressed, sliced and charged.

The crucial architectural fact is that 5GSM is a peer protocol between the UE and the SMF, not the AMF. The AMF is a pure relay for session-management messages: it never parses the 5GSM payload, it only reads the routing header that tells it which SMF (or which existing session) a message belongs to. This separation — mobility management in the AMF, session management in the SMF — is what lets a single registered UE fan out to many independent sessions on different slices and UPFs.

PDU Session Types

The PDU session type is chosen by the UE in the request and confirmed (possibly downgraded) by the SMF in the accept. It decides what kind of protocol data units the session carries and therefore how the UPF classifies and forwards them.

For IP types the SMF acts as the address allocator — it may draw from a local pool, from DHCP, or from an external server — and returns the result in the PDU address IE. For IPv6/IPv4v6 the accept carries an interface identifier and the actual /64 prefix arrives later in an IPv6 Router Advertisement. For Ethernet the core assigns no address at all; the UPF performs MAC learning so it can forward frames, which is what makes Ethernet sessions a natural fit for bridging a device transparently into an enterprise LAN or a time-sensitive-networking domain. If the UE asks for a type the subscription or DNN does not permit, the SMF may accept a narrower type (for example granting IPv6 when IPv4v6 was requested) and signals this back so the UE adjusts.

Establishment

The UE starts the procedure by building a 5GSM PDU Session Establishment Request. Because 5GSM never talks to the network directly, this message is placed in a NAS container inside the 5GMM transport message UL NAS TRANSPORT, which also carries the routing hints the AMF needs to dispatch it. The request states what the UE wants:

The AMF reads the 5GMM-level S-NSSAI and DNN, selects an SMF (via NRF discovery), and delivers the request to it over the service-based interface as an Nsmf_PDUSession_CreateSMContext operation. The SMF now does the heavy lifting. It authorises the session against the subscription retrieved from the UDM and against policy from the PCF (which returns PCC rules that shape the authorized QoS). It then selects a UPF and establishes an N4 session over PFCP: it installs Packet Detection Rules (PDR), Forwarding Action Rules (FAR), QoS Enforcement Rules (QER) and Usage Reporting Rules (URR), and it programs the N3 (and N9, if there is an intermediate UPF) GTP-U tunnel endpoints. The SMF also allocates the UE's address for IP types, or enables MAC learning for Ethernet.

With the UPF provisioned, the SMF returns a 5GSM PDU Session Establishment Accept, routed back through the AMF, which tells the UE exactly how the session will behave:

• Authorized QoS rules — the packet filters and, for each, the QoS flow (identified by its QFI) the filter maps to. These are the rules the UE applies to its uplink traffic.
• Authorized QoS flow descriptions — per-flow parameters: the 5QI, and for GBR flows the guaranteed and maximum bit rates (GFBR/MFBR).
• Session-AMBR — the aggregate bit-rate ceiling across all non-GBR flows of this session.
• The allocated address — the assigned IP address / prefix in the PDU address IE, or Ethernet parameters.
• The confirmed S-NSSAI, DNN, PDU session type and SSC mode, plus the RQ timer and any always-on indication.

None of this yet moves user data over the air. In parallel with delivering the accept, the AMF triggers the RAN side, which we look at next; only when both the NAS session and the radio/transport resources exist does the session become active.

Reading establishment in the logs

The 5GSM request and accept bracket the whole procedure, and the accept in particular is dense with the parameters that decide whether data will actually flow — the address, the QoS rules, the AMBR. A PDU Session Establishment Reject instead carries a 5GSM cause that names the reason.

Representative NAS decode — illustrative, values vary by vendor/build:

The Radio Side: NGAP, QoS Flows and DRBs

The NAS accept establishes the logical session. To carry its packets, the AMF (still relaying the SMF's decisions) sends the gNB an NGAP PDU Session Resource Setup Request. This message carries, per session, the PDU Session Resource Setup Request Transfer that the SMF built: the QoS Flow Setup Request List (one entry per QFI, each with its QoS parameters), the PDU Session Aggregate Maximum Bit Rate, and the UPF-side UL NG-U UP TNL Information — the GTP-U transport address and TEID the gNB must send uplink user data to over N3.

The gNB now performs the mapping that ties the core's QoS model to the radio. A PDU session's traffic is partitioned into QoS flows, each labelled by a QFI; the gNB decides how to pack those flows into Data Radio Bearers (DRBs). This flow-to-DRB mapping is the gNB's responsibility and can be many-flows-to-one-DRB. It is enforced on the air by the SDAP layer, which stamps a QFI into the SDAP header so the receiver can restore the flow identity. The gNB establishes the chosen DRBs on the radio with an RRCReconfiguration, and replies with PDU Session Resource Setup Response carrying its own DL NG-U UP TNL Information so the UPF learns where to send downlink data. The SMF pushes that downlink TEID to the UPF over N4, completing the bidirectional N3 tunnel.

Reading the radio side in the logs

The NGAP resource-setup exchange is where the logical session becomes a real bearer, so its trace shows the QoS-flow list, the flow-to-DRB mapping the gNB chose, and the two N3 TEIDs that must both be installed for the tunnel to carry traffic.

Representative gNB NGAP/RRC trace — illustrative, values vary by vendor/build:

SSC Modes and Session Continuity

Because the UPF is the anchor that holds the UE's IP address, what happens to that anchor as the UE moves determines whether the IP address survives. That behaviour is the Session and Service Continuity (SSC) mode, requested by the UE and confirmed by the SMF at establishment. There are three modes, defined in TS 23.501.

The intuition: SSC mode 1 optimises for address stability — the anchor is fixed even if the UE roams far from it, so upper-layer sessions never notice. SSC mode 2 and SSC mode 3 optimise for path efficiency, letting the network re-anchor onto a UPF nearer the UE's new location; mode 3 hides the switch by overlapping old and new paths (the UE gets a second address and migrates flows before the first is torn down), while mode 2 accepts a brief break. Edge deployments lean on mode 3 so that a session can follow a user toward a local breakout point without dropping traffic. The SMF may reject the requested mode and grant a different allowed one, based on the DNN and subscription.

Modification, Release and User-Plane Activation

A session is not frozen after establishment. Modification changes an existing session — adding, changing or removing QoS flows, updating authorized QoS rules, or revising the Session-AMBR. It can be UE-requested (PDU Session Modification Request) or network/PCF-requested; either way the SMF drives it with a PDU Session Modification Command, the UE confirms with PDU Session Modification Complete, and the SMF re-provisions the UPF over N4 and updates NGAP/DRB resources as needed. Adding a GBR flow for a video call, for example, is a modification that inserts a new QFI and its DRB.

Release tears the session down and frees its resources. It too can start from the UE (PDU Session Release Request) or the network; the SMF issues a PDU Session Release Command, the UE answers PDU Session Release Complete, the N4/PFCP session and UPF resources are removed, and the gNB releases the associated DRBs via NGAP PDU Session Resource Release. The PDU Session ID is then free to reuse.

A distinct and very common event is user-plane activation. When a UE in CM-IDLE has data to send (or is paged for downlink data), it runs the Service Request procedure. The NAS session was never deleted while idle — only the radio DRBs and the N3 tunnel were torn down. Service Request re-activates the user plane: the AMF triggers PDU Session Resource Setup toward the gNB again, DRBs are re-established and a fresh N3 tunnel is built, without re-running the full 5GSM establishment. This is why the logical session can persist for hours while its transport comes and goes with activity.

LTE ↔ NR

Summary

A PDU session is one object living on three planes, and a "no data" fault is fastest to isolate by asking which plane broke. Walk it in order: the 5GSM signalling (did the Establishment Accept arrive with a PDU address and a default QFI, or a Reject with a cause?), the N4/PFCP provisioning of the UPF (was the tunnel and address actually programmed?), and the NGAP + RRC resource setup (were the QoS flows mapped to DRBs and both N3 TEIDs installed?). The session is only ACTIVE when all three are in place.

Two facts save the most time. First, the AMF is only a relay — a session problem is usually an SMF-selection, SMF, PCF, or UPF problem, not an AMF one. Second, an idle UE keeps its logical session and IP; a data stall there is a user-plane activation (Service Request) issue, not an establishment one. Read the procedure message by message, plane by plane, and the first field that does not line up is your root cause.

Interview quickfire