Sessions, flows and slices — what the core actually establishes

The core note says which functions exist. This note says what they actually establish for you. A PDU session is the thing that exists when a phone is "on the internet"; a QoS flow is the finest grain at which the network promises anything about it; a slice is the logical network it belongs to. All three are core-network objects with radio consequences, and the consequences are where this folder's two halves meet.

In one line. LTE made quality of service a property of an end-to-end bearer, so differentiating two kinds of traffic meant building another one through the whole system. 5G makes it a marking inside an existing session — six bits in a tunnel header, outside the user's packet — which is cheap enough to do per application. Everything else here follows from that: why SDAP had to be invented, why one QoS model covers Ethernet as well as IP, and why the whole of 5QI reduces to one instruction handed to a scheduler.

The concepts this note covers

Each concept has a page of its own. This note is the narrative — the group read as one argument, with the connective tissue that a page-per-concept cannot carry. The pages are the definitions, and each one shows what to learn before it.

The session, and what is inside it

What it is. TS 23.501 §5.6.1: the 5GC supports a PDU Connectivity Service, "a service that provides exchange of PDUs between a UE and a data network identified by a DNN", delivered "via PDU Sessions that are established upon request from the UE". Full definition: PDU session.

Established by the device, over 5GSM signalling that travels through the AMF unread and terminates at the SMF, which owns it for its lifetime.

A device normally holds several at once — internet, ims, perhaps an enterprise network — independent in anchor, address, policy and possibly slice. Nothing about a device's connectivity is singular.

The name that selects everything

DNN — TS 23.501 §5.9.6. The 5G spelling of the APN, and it selects far more than a destination: which SMF, therefore which UPF, therefore where packets exit at N6, and which policy applies.

If the name is unsupported and no SMF can be found, §5.6.1 is blunt — the AMF "shall reject the NAS Message containing PDU Session Establishment Request... with a cause indicating that the DNN is not supported" — unless the PCF supplied a DNN replacement policy. So the name the device sends is a request, and the name the network uses may not be it; the SMF is given both.

Five types, and the two that are not IP

PDU session type — §5.6.1 defines IPv4, IPv6, IPv4v6, Ethernet, Unstructured, and "Each PDU Session supports a single PDU Session type".

Ethernet is why 5G is pitched at factories. An Ethernet PDU session makes the 5G system a layer-2 segment: the device sends frames, the UPF bridges them onto a real LAN at N6, and everything there sees an ordinary host on the same broadcast domain. Industrial protocols — PROFINET, EtherCAT — are Ethernet protocols, not IP ones, and under this session type they simply run.

It also explains an odd line in two function lists. Both the SMF and the UPF carry "Functionality to respond to Address Resolution Protocol (ARP) requests and / or IPv6 Neighbour Solicitation requests based on local cache information for the Ethernet PDUs". A radio link is expensive and broadcast traffic is constant, so the network answers ARP on the device's behalf rather than flooding it over the air. That is layer-2 emulation sitting in a mobile core specification, and it is there entirely for this session type.

Quality of service, as 5G does it

The flow

QoS flow — TS 23.501 §5.7.1.1: "The QoS Flow is the finest granularity of QoS differentiation in the PDU Session." Either GBR or Non-GBR; a GBR flow adds guaranteed and maximum bit rates and must be admitted, a non-GBR flow is best effort within its priority.

One flow is described to three audiences, and each gets a different object:

Every session has a default flow permanently — §5.7.1.1 requires the flow associated with the default QoS rule to "remain established throughout the lifetime of the PDU Session", and it "should be a Non-GBR QoS Flow". Connectivity therefore never depends on a reservation succeeding.

The marking, and where it lives

QFI — §5.7.1.1, and the clause repays a slow reading:

"The QFI is carried in an encapsulation header on N3 (and N9) i.e. without any changes to the e2e packet header. QFI shall be used for all PDU Session Types."

Three decisions in one sentence. The marking lives in the GTP-U header, not the packet; the user's packet arrives bit-identical, which is what lets the network treat traffic it did not author and cannot read; and putting it in the encapsulation is what makes one QoS model work for Ethernet and Unstructured sessions too, which have no IP header to mark.

The promise

5QI — §5.7.2, standardised in Table 5.7.4-1. One scalar standing for a resource type, a priority, a packet delay budget and a packet error rate.

5QI 9 is the internet, at priority 90 — nearly the lowest in the table. Ordinary web traffic is by design the thing that gives way.

5QI 85 is where this table meets layer 1. Five milliseconds at one error in 100,000 is URLLC expressed as a scheduling instruction, and everything the NR notes describe as machinery for meeting it — short slots, high numerology, HARQ budgets, conservative CQI — exists to satisfy a row of this table.

"Delay-critical GBR" is a third resource type, and its rows are the only ones carrying a Maximum Data Burst Volume — 255, 500, 1354 or 17000 bytes. A latency promise is meaningless without a bound on how much arrives at once, so the RAN is told both how fast and how much.

The tunnel underneath it all

GTP-U — TS 23.501 §8.3. The user packet is wrapped and carried over UDP/IP across the transport network, for three reasons: the device's address must not depend on where it is; per-session and per-flow identity must survive the transport network (the TEID and the QFI); and the user's packet must arrive unmodified.

The control plane is HTTP/2 and the user plane is GTP-U. Both statements are true at once, and this is the one to remember whenever the 5G core is described as "all REST".

Slicing

Network slice — TS 23.501 §5.15. What is sliced, and what is not:

The radio is not sliced, and it is worth being honest about that. Marketing material showing the air interface cut into coloured slabs is describing something the specification does not do. A slice is a core-network construct with radio consequences, and the consequence travels as a QoS profile.

How a slice is named

S-NSSAI — §5.15.2. An SST (slice/service type) and an optional SD (differentiator). The standardised SST values are 1 eMBB, 2 URLLC, 3 MIoT, 4 V2X, 5 HMTC, 6 HDLLC, 7 GBRSS — so the three service classes of TR 38.913 reappear here as slice types.

Two hard numbers. At most eight S-NSSAIs in the Allowed or Requested NSSAI (§5.15.2.1); at most sixteen Subscribed S-NSSAIs sent by the UDM (§5.15.3). A subscription may entitle a device to sixteen slices and let it be registered in eight.

A non-standard S-NSSAI may not travel — it "shall not be used by the UE in access stratum procedures in any PLMN other than the one to which the S-NSSAI is associated". That is why roaming needs an explicit mapping of serving-PLMN values to home-PLMN ones, and why the standardised SSTs exist at all.

Why slicing needed the SBA first

Standing up another logical core means standing up more instances of control functions. Under LTE's node model each instance needs its peers' addresses configured, and the cost grows with slices × interfaces. Under the service-based architecture instances register themselves with the NRF and are found by discovery filtered on S-NSSAI.

Slicing is not a feature bolted onto the SBA — it is the SBA's most direct consequence.

Continuity, and the rules

SSC mode — §5.6.9. What happens to your address when you outrun your anchor: mode 1 keeps the anchor and the address forever; mode 2 breaks before making; mode 3 makes before breaking, so old and new coexist briefly.

One trade, stated three ways: address stability against path length. Mode 1 is what a phone uses, and is why your address does not change as you cross a city. Mode 3 is what makes edge computing usable — and it is only possible because the CP/UP split lets the SMF stand up a second anchor without disturbing the first.

Policy, in two directions

Policy control — TS 23.503. PCC rules go into the network: the PCF gives them to the SMF, which programs the UPF. URSP rules go into the device, over NAS, telling it which application's traffic uses which slice, DNN and session.

URSP is the direction people miss, and it is the one that makes slicing work. The decision which slice does this app use can only be made where the app is. Without URSP a device would have no way to choose among its own sessions, and the network would have to classify traffic it may not be able to read.

TS 23.501 §5.6.1 even assumes it is current — "The expectation is that the URSP in the UE is always up to date" — and then spends a paragraph on what to do when it is not, which is DNN replacement. The specification knows a rule living in the device can go stale.

Sources

cd ~/Documents/md-engine/"Courses (RAW)/5G Topics"
pdftotext -layout ts_123501v190700p.pdf - | grep -n -A18 "^5.7.1.1 *QoS Flow"
pdftotext -layout ts_123501v190700p.pdf - | grep -n -A20 "Table 5.15.2.2-1"
pdftotext -layout ts_123501v190700p.pdf - | grep -n "at most eight S-NSSAIs"