PDU Sessions in 5G: What They Are and How QoS Rides on Top
A PDU Session is the 5G Core's unit of data connectivity. Here's how one gets established, what lives inside it, and how QoS Flows map down to radio bearers.
If you've come to 5G from LTE, the PDU Session is the concept most likely to trip you up — not because it's hard, but because it looks like a PDN connection and behaves differently in ways that matter.
The short version: a PDU Session is a logical association between a UE and a Data Network, established and controlled by the 5G Core. It's the container. What makes 5G interesting is what the network can do inside that container.
The distinction worth holding onto from the start: a PDU Session is not "an internet connection." It's a Core-managed session with a type, an address, a set of policies, and — critically — one or more QoS Flows that can each be treated differently.
What a PDU Session actually is
PDU stands for Protocol Data Unit. The session gives the UE a path for exchanging those PDUs with a Data Network, which might be the public internet, an operator service network, a private enterprise LAN, an industrial network, or an edge application.
Three network functions do the work:
The AMF handles access and mobility, and carries session-management NAS messages without interpreting them. The SMF is the actual session controller — it owns establishment, modification, and release. The UPF forwards packets and enforces what the SMF told it to enforce.
That separation is the whole point of the 5G Core design. Control decisions and packet forwarding scale independently.
PDU Session vs RRC connection
These get conflated constantly, so it's worth being blunt: they live at different layers and have different lifetimes.
An RRC connection is a radio-access relationship between UE and gNB. A PDU Session is a Core-level connectivity construct. A UE can hold a PDU Session while its RRC state changes underneath — the session context survives, even though the radio connection doesn't.
Session identity: PDU Session ID and DNN
Each session carries a PDU Session ID, which is how UE and network keep multiple sessions apart. The DNN (Data Network Name) picks which data network the session connects to — functionally the APN's successor, though the surrounding procedures differ.
One UE, three sessions, three DNNs is a completely normal configuration:
Each session gets its own type, address, QoS Flows, policies, and user-plane path.
PDU Session types
5G defines five, and the choice matters more than it first appears:
IPv4 and IPv6 are the obvious ones. IPv4v6 is dual-stack, useful during transition — the UE requests it and may get both, one, or a rejection depending on what the network and subscription support.
Ethernet is the one that changed what 5G could sell. Instead of handing the UE IP packets, the session carries Ethernet frames — which means a 5G system can slot into an existing enterprise or industrial LAN without forcing an IP redesign. If you've wondered why Private 5G pitches lean so hard on "it's just another switch port," this is why.
Unstructured carries data that doesn't follow IP or Ethernet semantics at all. Niche, but it exists for non-IP IoT transport.
How a session gets established
The full 3GPP procedure has considerably more messages, identities, and security steps than this. But the architectural skeleton is what you need to reason about:
Walking it through:
The UE sends a PDU Session Establishment Request carrying a PDU Session ID, requested type, DNN, and SSC mode. This travels as NAS payload — the AMF forwards it rather than processing the session details.
The AMF selects an SMF based on DNN, S-NSSAI, subscription data, local configuration, and load.
The SMF builds the session context: allocating the IP address or prefix, deciding QoS rules, consulting the PCF where policy control applies, and selecting one or more UPFs. UPF selection is where deployment intent shows up — a latency-sensitive service gets an edge UPF, ordinary internet traffic gets a central one.
The SMF programs the UPF over N4 using PFCP, telling it how to detect, forward, and meter packets belonging to this session.
The gNB is given the QoS profiles it needs and sets up radio resources. This is the handoff point where the Core's QoS model becomes the RAN's problem.
Finally, a PDU Session Establishment Accept goes back to the UE with the accepted type, address information, selected SSC mode, and authorised QoS rules.
QoS Flows: the part that actually matters
Here's the concept that separates 5G session management from what came before.
A QoS Flow is the finest granularity of QoS differentiation available inside a PDU Session. One session, multiple flows, each treated differently:
The session provides connectivity. The flows provide differentiated connectivity. If you take one thing from this article, take that.
QFI, 5QI, and what they each do
Every QoS Flow carries a QFI (QoS Flow Identifier) — the label saying which flow a packet belongs to. It's an identifier, nothing more.
The 5QI (5G QoS Identifier) carries the actual characteristics: resource type, priority level, packet delay budget, packet error rate, and burst parameters.
QFI answers which flow. 5QI answers what treatment. Keeping those separate saves a lot of confusion later — and the QoS Flow deep dive covers the full 5QI table, ARP, reflective QoS, and Session-AMBR.
GBR vs non-GBR
Non-GBR flows get no bit-rate guarantee — general internet traffic lives here. GBR flows get a guaranteed bit rate with resources reserved accordingly, which is what conversational voice needs. Delay-critical GBR adds tighter delay handling for URLLC.
Mapping down to the radio
The chain from Core to air interface runs through SDAP, the NR user-plane layer that maps QoS Flows onto Data Radio Bearers:
The mapping isn't one-to-one. Multiple QoS Flows can share a DRB when their requirements are similar enough; flows with genuinely different needs get separate bearers. The gNB decides based on QoS configuration and its own scheduling design.
So the hierarchy is: PDU Session (connectivity) → QoS Flow (differentiation, identified by QFI, characterised by 5QI) → DRB (radio transport).
What this looks like on a real phone
A smartphone streaming video while a call comes in doesn't open a second session. It uses one:
One PDU Session to the internet DNN. Inside it, a GBR flow for the voice, a flow for video, a non-GBR flow for background sync. Same connectivity, three different treatments, all managed by the SMF and enforced by the UPF and gNB.
Sessions don't sit still
A PDU Session is dynamic. Modification can be triggered by the UE or the network — adding a QoS Flow when an application starts, changing parameters, or removing a flow when it's no longer needed. Release tears the session down when the UE requests it, the network decides to, or something fails.
SSC (Session and Service Continuity) mode governs what happens when the user-plane anchor needs to change. Mode 1 keeps the anchor put. Mode 2 releases and re-establishes. Mode 3 sets up the new path before dropping the old one, so the application sees continuity. This matters most for edge computing, where the whole point is keeping the UPF near the UE:
Choosing the right SSC mode is what stops an edge application from breaking every time the user moves.
Session and Service Continuity modes
The specification defines three SSC modes, and the choice determines what happens to a session's anchor when the device moves.
SSC mode 1 — the anchor UPF never changes. The IP address is preserved for the life of the session, regardless of how far the UE moves. This is the conservative option and the right one for anything holding long-lived connections: VPNs, IMS voice, persistent TCP sessions.
SSC mode 2 — the network may release the session and require the UE to establish a new one, with a new address. Break-before-make. Disruptive to active connections, but it lets the network relocate the anchor closer to the device.
SSC mode 3 — make-before-break. A new session is established through a new anchor while the old one is still up, giving the application a window to migrate before the old address is withdrawn.
Mode 3 is the one that matters for edge computing. As a device moves away from the edge site anchoring its session, the traffic path lengthens and the latency advantage erodes. Mode 3 allows the anchor to follow the device without dropping traffic, provided the application can handle a changing source address.
Uplink classifiers and branching points
A session does not have to route all its traffic through one anchor. Two mechanisms let the SMF insert a second UPF into the path:
An uplink classifier (UL CL) inspects uplink packets and diverts matching traffic — typically by destination prefix — to a local anchor, while the rest continues to the central one. The UE is unaware; it still sees one session and one address.
A branching point does something similar for multi-homed IPv6 sessions, splitting traffic across two anchors by source prefix. Here the UE does participate, because it holds two prefixes and chooses between them.
Both exist for the same reason: to get local traffic onto a local network without giving the device a second session to manage.
Sessions and network slicing
A PDU Session is always associated with exactly one S-NSSAI — one network slice. That's a hard constraint worth remembering.
A UE needing both eMBB and URLLC treatment needs two PDU Sessions, one per slice, potentially served by different SMFs and different UPFs on the same physical infrastructure.
Establishment in more detail
The establishment procedure is worth walking through once, because the division of labour explains most of what can go wrong.
The UE sends a PDU Session Establishment Request as a NAS message. It is carried transparently through the gNB to the AMF, which does not interpret it — the AMF's job is to select an SMF, using the requested S-NSSAI and DNN.
The SMF does the substantive work: it authorises the request against subscription data from the UDM, selects a UPF, requests policy from the PCF, and allocates an IP address or prefix. It then programs the UPF over N4 using PFCP, installing the packet detection, forwarding and QoS enforcement rules that will govern the session.
Only then does the RAN get involved. The SMF sends the QoS profiles to the gNB via the AMF, and the gNB establishes the corresponding radio bearers and returns its tunnel endpoint. The SMF passes that endpoint to the UPF, completing the user-plane path in both directions.
The ordering matters: the core network commits to the session before the RAN is asked whether it can support it. When the RAN cannot, the failure arrives late, and the SMF must unwind work already done.
Where establishment fails
Slice not allowed. The requested S-NSSAI is not in the UE's allowed NSSAI for the current registration area. Rejected at the AMF, before an SMF is even chosen.
DNN not subscribed. The UDM has no matching subscription. Rejected at the SMF.
No UPF available. No UPF can serve the requested combination of slice, DNN and location. This is a deployment problem that surfaces as an establishment failure.
RAN resource failure. The gNB cannot admit the requested GBR flows. The session may still come up with the default flow while the GBR flows are rejected — a partial success that is easy to misread as a complete one.
Address allocation failure. The pool for that DNN is exhausted. Rare, and unmistakable once observed.
The mental model
If you're preparing for an interview or a design review, this is the compression:
A PDU Session is Core-managed connectivity to one Data Network, on one slice, with one PDU type.
A QoS Flow is the unit of differentiation inside it — identified by QFI, characterised by 5QI.
A DRB is the radio bearer that carries it, mapped from QoS Flows by SDAP.
The SMF decides, the UPF enforces, the gNB schedules.
Get those four relationships straight and most of 5G session management falls into place. QoS in 5G isn't a radio feature bolted onto a pipe — it's an end-to-end architecture that happens to terminate at the air interface.
Further reading
- 3GPP TS 23.501 — System architecture for the 5G System, session management and QoS framework
- 3GPP TS 23.502 — Procedures for the 5G System, PDU Session establishment and modification
- 3GPP TS 29.244 — PFCP, the N4 protocol between SMF and UPF
- 5G QoS Flows — 5QI, ARP, reflective QoS in detail
- 3GPP TS 37.324 — SDAP specification
Related Articles
Non-Terrestrial Networks: 3GPP Satellites, Delay Budgets, and Direct-to-Device
How 3GPP adapted NR for satellites: LEO/MEO/GEO trade-offs, the timing advance and HARQ changes long delays forced, transparent versus regenerative payloads, and what direct-to-device really delivers.
What Is 5G NR? Numerology, Frequency Ranges, and the Flexible Frame
5G NR explained for engineers: scalable numerology, FR1 and FR2, the flexible slot structure, bandwidth parts, and what actually changed from LTE.
5G Interview Questions: What Gets Asked and How to Answer It
A structured 5G interview guide: the questions that actually come up across radio, RAN, core and QoS, worked troubleshooting and system-design scenarios, and a framework for answering well.