PDU session — The connection itself — a device, a data network, and everything between

5G Systems Notes · Concept map · PDU session Route · Hierarchy · Index · All concepts · Hub

Sessions, flows and slices

Where it sits

Sits atLevel 3 of the hierarchy · Sessions, flows and slices · explained
Learn firstDNN · SMF — 5 concepts in the full chain, see the paths
UnlocksPDU session type · QFI · SSC mode · 5GSM
Primary clauseTS 23.501 §5.6.1
Used inref-session 14 · ref-ue-state 3 · index 2 · ref-core 2
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 thing that is actually established when a device gets on the internet: an association between the device and a data network named by a DNN, carrying packets of one type. TS 23.501 §5.6.1 calls the service it provides the PDU Connectivity Service.

Who does what. Established on request from the device, modified by either end, released by either end, all through 5GSM signalling over N1 — which travels through the AMF without the AMF reading it, and terminates at the SMF, which owns the session for its lifetime.

A device has several at once, and that is the normal case. One to internet, one to ims for calls, perhaps one to an enterprise network. They are independent: different UPF anchors, different IP addresses, different policy, possibly different slices. Nothing about a device's connectivity is singular.

Each session carries a single type — §5.6.1 is explicit: "Each PDU Session supports a single PDU Session type", chosen at establishment. An Ethernet session and an IPv6 session are two sessions.

What is inside it. A PDU session is a container for QoS flows, and §5.7.1.1 requires that one of them — the flow associated with the default QoS rule — exists for the whole lifetime of the session. So a session always has at least one flow, and that flow is what provides basic connectivity while the others come and go.

Why this replaced the bearer, and what changed. In LTE, quality of service was a property of a bearer, and a bearer ran end to end — radio, core, and all the signalling in between. Wanting different treatment for two kinds of traffic meant establishing another bearer through the whole system.

In 5G the session is the container and the QoS flow is the unit of differentiation, and a flow is cheap: it is a marking, not an end-to-end construct. The radio side is decoupled — mapping a flow to a radio bearer is SDAP's job and nothing above SDAP needs to know how it was done.

Where the RAN sees it. It does not, quite. The base station sees a GTP-U tunnel on N3 per session and a QoS profile per flow inside it. The session as such is a core-network object.

Read on

This concept is read as part of one argument in ref-session, 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 PDU session (level 3) you first need 5 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:
Level Learn these
0 5G Core
1 DNN · Network function · Reference point
2 SMF
Immediately before PDU session: SMF, DNN.
Keep going — where this sits on the route
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 · PDU session Top · Concept map · Hub