5G QoS Model (5QI / QFI / ARP) in 5G NR
The end-to-end QoS framework: QoS flows, 5QI tables, GBR vs non-GBR and ARP.
In 5G, quality of service is not a property of a bearer — it is a property of a QoS flow. Every IP packet inside a PDU session is tagged with a QFI, and that single number tells the RAN exactly how the packet should be treated. This is the finest granularity of differentiated treatment in the whole system, defined in TS 23.501, and everything else — the 5QI, ARP, the bit-rate limits, the QoS profile and the SDAP mapping — hangs off it.
Introduction
The 5G QoS model (TS 23.501) is the framework that decides how every packet a UE sends or receives is treated end-to-end — how it is scheduled, queued, rate-limited, admitted and dropped. It lives across three domains at once: the core (where policy is authored and enforced by the SMF/UPF), the radio (where the gNB scheduler serves each bearer), and the UE (where uplink packets are classified). Understanding it means understanding one object — the QoS flow — and the parameters that hang off it.
You meet this model the moment a UE has a usable connection. Right after registration the UE establishes at least one PDU session, and that session comes up with a default QoS flow before a single byte of user data moves. From then on, every new service — a voice call, a video stream, a URLLC control loop — either reuses an existing flow or triggers a new one, each with its own QFI, 5QI and treatment. Nothing on the user plane happens outside a QoS flow.
It matters because 5G deliberately carries wildly different traffic on one always-on pipe. Voice, best-effort browsing, buffered video and factory automation share the same PDU session and the same radio, yet each demands different delay, loss and rate behaviour. The QoS flow is the mechanism that lets one network give each of them the right treatment without building a separate bearer for every one — the rigidity that defined LTE.
On this page
Why the QoS flow is needed
In plain words: think of a PDU session as one delivery truck driving from the internet to your phone. Inside it, every parcel wears a coloured sticker — the QFI. The sticker, not the truck, tells the depot how to handle the parcel: which shelf, how fast, how carefully. LTE gave every kind of parcel its own dedicated truck; 5G puts them all on one truck and sorts by sticker, so adding a new kind of parcel never means dispatching a new truck.
Concretely, three things force this design. First, one PDU session must carry mixed traffic: an always-on data session simultaneously handles signalling, streaming, and interactive apps that want opposite treatment. Second, the network needs a single, cheap tag that every node — UPF, gNB, UE — can read to apply the right policy without re-inspecting packet contents at each hop. Third, the flow-to-radio-bearer relationship must be able to change without tearing anything down, so the RAN can rebalance which flows share a DRB as conditions shift. The QoS flow, identified by a 6-bit QFI and marked in the SDAP header on the radio and the GTP-U header on N3, is exactly that tag.
A QoS flow (identified by QFI) is a stream of packets inside one PDU session that all receive identical forwarding treatment — scheduling weight, admission thresholds, queue management, drop policy.
It decouples QoS from the bearer. Many flows can share one DRB, and the flow-to-bearer mapping can change without re-establishing bearers — far more flexible than LTE's one-bearer-per-treatment model for the mixed traffic on a single always-on PDU session.
The SMF assigns each flow a QFI and a QoS profile; the UPF classifies and marks downlink packets with the QFI; SDAP in the gNB maps each QFI onto a DRB. See SDAP and QoS Flow Mapping.
The QoS Flow — the atom of 5G QoS
A QoS flow is the finest granularity of QoS differentiation within a PDU session. Every packet mapped to the same QoS flow gets the same forwarding treatment — scheduling weight, admission thresholds, queue management, drop policy. A flow is identified by its QFI (QoS Flow Identifier), a 6-bit value in the range 0–63 (so up to 64 flows per PDU session) that is unique within that PDU session and is carried in the GTP-U encapsulation header over N3 and, on the radio side, in the SDAP header.
There are two kinds of QoS flow. A GBR flow is created on demand for a specific service — a voice call, a video session, a URLLC stream — and carries a guaranteed bit rate that admission control must reserve. A Non-GBR flow is best-effort and needs no reservation; the very first flow of most PDU sessions is the default Non-GBR flow that carries ordinary internet traffic. Each flow also has a QoS Flow level set of parameters: a 5QI, an ARP, optionally bit-rate limits, and — for the default flow — an association with the PDU session's Session-AMBR.
Hierarchy in one line: a UE has one or more PDU sessions; each PDU session carries one or more QoS flows (each a QFI); each QoS flow is mapped by SDAP onto a DRB. The QoS flow is the atom — the DRB is just the radio pipe it rides in, and the PDU session is the end-to-end tunnel that contains them all.
The 5QI and its standardized characteristics
Every QoS flow references a 5QI (5G QoS Identifier) — a scalar that points to a set of QoS characteristics. Because a large block of values is standardized, the SMF can signal just the 5QI number and every node already knows how to treat it. Two other forms exist: a pre-configured 5QI (characteristics loaded into the gNB by O&M) and a dynamically-assigned 5QI, where the characteristics are signalled explicitly inside the QoS profile because no standardized value fits.
The characteristics a 5QI resolves to are the following. The first four apply to every flow; the last two apply only to GBR and Delay-critical GBR flows.
| Characteristic | Applies to | Meaning |
|---|---|---|
| Resource Type | All | One of GBR, Non-GBR, or Delay-critical GBR. It decides whether the flow gets a guaranteed bit rate and which delay/error semantics apply. |
| Priority Level | All | Relative scheduling priority when resources are scarce — lower value = higher priority. The gNB scheduler uses it to arbitrate between flows competing for the same air interface. The standardized range runs 1–127. |
| Packet Delay Budget (PDB) | All | Upper bound (typically 98th percentile) for the one-way delay between the UE and the UPF anchor. It is split into a core-network part and a radio part (the latter feeds the scheduler's deadline). For Delay-critical GBR it is a hard bound on the burst. |
| Packet Error Rate (PER) | All | Upper bound on the ratio of packets processed by the sender's link layer but not successfully delivered — it sets the residual reliability target (e.g. the RLC/HARQ operating point). |
| Averaging Window | GBR / Delay-critical | The time window over which GFBR and MFBR are computed. A rate only means something relative to a window; the standardized default is 2000 ms. |
| Maximum Data Burst Volume (MDBV) | Delay-critical GBR | The largest volume of data the flow may require to be served within the PDB. It bounds burst size so the scheduler can guarantee the deadline for that burst. |
Read direction of Priority Level: a common trap. Priority Level is like a race position — Priority Level 1 beats Priority Level 20. So IMS signalling at Priority 10 is served ahead of default best-effort data at Priority 90. Do not confuse it with the ARP priority level, which is a different number used at a different time.
The standardized 5QI table
TS 23.501 Table 5.7.4-1 fixes a set of standardized 5QIs so the whole network shares one meaning for each value. The three resource-type families read very differently: GBR flows trade moderate delay for a reserved rate, Non-GBR flows accept queueing but demand low loss, and Delay-critical GBR flows demand both a tiny delay and a hard per-burst deadline. A representative subset:
5QI | Resource Type | Priority | PDB | PER | MDBV | Example service |
|---|---|---|---|---|---|---|
| 1 | GBR | 20 | 100 ms | 10⁻² | — | Conversational voice |
| 2 | GBR | 40 | 150 ms | 10⁻³ | — | Conversational video (live) |
| 3 | GBR | 30 | 50 ms | 10⁻³ | — | Real-time gaming, V2X, process automation |
| 5 | Non-GBR | 10 | 100 ms | 10⁻⁶ | — | IMS signalling |
| 6 | Non-GBR | 60 | 300 ms | 10⁻⁶ | — | Video (buffered streaming), TCP-based data |
| 9 | Non-GBR | 90 | 300 ms | 10⁻⁶ | — | Default flow — general best-effort internet |
| 82 | Delay-critical GBR | 19 | 10 ms | 10⁻⁴ | 1530 B | Discrete automation (URLLC) |
| 83 | Delay-critical GBR | 22 | 10 ms | 10⁻⁴ | 1354 B | Discrete automation / V2X (higher rate) |
Reading the table: voice (5QI 1) tolerates a loose PER of 10⁻² because a lost voice frame is inaudible, but needs a tight 100 ms PDB. Best-effort data (5QI 9) is the opposite — generous 300 ms delay, but a strict 10⁻⁶ PER because TCP treats loss as congestion. URLLC (82/83) demands both a 10 ms budget and a hard MDBV per burst, which is why it is a separate resource type rather than just an aggressive GBR flow.
ARP — who gets in, and who gets bumped
ARP (Allocation and Retention Priority) is a separate attribute of every QoS flow, and it is deliberately not part of the 5QI. Where the 5QI describes how a flow's packets are forwarded once admitted, ARP governs admission and retention — what happens when there are not enough resources to go around, at setup time or during congestion.
| ARP field | Range | Meaning |
|---|---|---|
| Priority Level | 1–15 (1 = highest) | Used only at admission/retention time to decide which flow to admit or drop first when resources are congested. Values 1–8 are reserved for resources within one operator's domain. |
| Pre-emption Capability | may / shall-not trigger | May this flow take resources already held by a lower-priority flow when it needs to be admitted? |
| Pre-emption Vulnerability | pre-emptable / not | May this flow's resources be taken away to admit a higher-priority flow? |
5QI vs ARP: think of a restaurant. The 5QI is how fast and carefully your meal is cooked once you are seated. ARP is the door policy — who gets a table when the place is full, and whose table can be given away. An emergency-call flow is typically given a high ARP priority with pre-emption capability set and vulnerability cleared, so it can bump others and never be bumped itself.
Bit rates — GFBR, MFBR, and the AMBRs
Guaranteed and non-guaranteed flows are policed by different bit-rate parameters, and the two families never share a budget. Per-flow rates apply to GBR flows; aggregate rates apply across Non-GBR flows only.
| Parameter | Scope | Enforced by | Meaning |
|---|---|---|---|
GFBR | Per GBR flow | gNB (admission) | Guaranteed Flow Bit Rate — the rate the network commits to provide as long as the flow stays within it. Admission control reserves radio resources for this. |
MFBR | Per GBR flow | UPF / gNB | Maximum Flow Bit Rate — the ceiling; traffic above MFBR may be discarded or delayed by the rate-limiter (measured over the averaging window). |
Session-AMBR | Per PDU session | UPF (DL) / UE (UL) | Aggregate ceiling across all Non-GBR flows of one PDU session. The UPF polices it downlink; the UE polices it uplink. |
UE-AMBR | Per UE (all sessions) | gNB (RAN) | Aggregate ceiling across all Non-GBR flows of the UE. The gNB caps the sum of served Non-GBR traffic; it must not exceed the subscribed UE-AMBR. |
Note: the AMBRs apply only to Non-GBR traffic. GBR and Delay-critical GBR flows are governed by their own GFBR/MFBR and are not counted against the AMBR budgets — so a burst of GBR traffic never starves the AMBR pool and vice versa.
The QoS profile, QoS rules and UPF enforcement
The pieces above have to reach three different places: the gNB (so it can schedule), the UE (so it can classify uplink packets), and the UPF (so it can classify and mark downlink packets). Each gets its own object, all derived by the SMF from the same policy.
To the gNB — the QoS profile. The SMF builds a QoS profile per QoS flow and sends it to the gNB through the AMF over NGAP, inside the PDU Session Resource Setup Request procedure — the QoS flow parameters travel in the PDU Session Resource Setup Request Transfer IE. The profile carries the QFI, the 5QI (or the explicit characteristics for a dynamic 5QI), the ARP, and — for GBR flows — the GFBR, MFBR and (for delay-critical) the MDBV, plus a Reflective QoS indicator where relevant. The gNB never invents QoS; it enforces the profile it is handed.
To the UE — QoS rules. The UE receives QoS rules over NAS signalling (the PDU Session Establishment Accept) from the SMF. Each rule contains a packet filter set and the associated QFI, telling the UE how to classify its uplink packets onto the right QoS flow. A rule may be signalled explicitly, or it may be derived by the UE through reflective QoS (below), in which case no explicit rule is sent for it.
At the UPF — PDR, QER and marking. The UPF is programmed by the SMF over N4 (PFCP) with Packet Detection Rules (PDR) that match downlink packets to a QoS flow, and QoS Enforcement Rules (QER) that police the flow's rate (MFBR, Session-AMBR). Having classified a packet, the UPF writes the QFI into the GTP-U extension header (the PDU Session Container extension) on N3 and may set a Reflective QoS Indicator (RQI). It also performs transport-level packet marking — setting the DSCP of the outer IP header so the transport network between UPF and gNB can honour the class.
One policy, three consumers: the SMF turns a PCC rule (from the PCF) into a QoS profile for the gNB (over NGAP), a QoS rule for the UE (over NAS), and a PDR/QER pair for the UPF (over N4/PFCP). All three describe the same QoS flow from different vantage points.
From QoS flow to DRB — the SDAP mapping
The QoS flow lives end-to-end (UE ↔ UPF); the DRB lives only over the radio (UE ↔ gNB). SDAP is the sublayer that bridges them: it maps each QFI onto a DRB. The mapping can be one-to-one or many-to-one, and one QoS flow is always the flow's default DRB. On the uplink the UE decides the mapping either from an explicit RRC configuration (SDAP-Config inside the DRB-ToAddMod) or by reflective QoS, where it mirrors the observed downlink QFI→DRB relationship — controlled by the RDI bit in the SDAP header and the RQI from the core.
Below SDAP, each DRB carries its packets down through PDCP, RLC and MAC. The gNB scheduler uses the QoS characteristics behind each flow's 5QI — Priority Level, PDB, PER, and any GFBR — to decide how to serve the DRBs against each other and against other UEs. Because SDAP sits above PDCP, changing which flows share a DRB is a lightweight reconfiguration, not a bearer teardown. See Radio Bearers for how SRBs and DRBs are structured.
⚠ Common pitfalls / gotchas
- Confusing the two Priority Levels. The
5QIPriority Level (scheduling) and theARPPriority Level (admission) are different numbers with different ranges used at different times — a flow can be high-priority to schedule yet low-priority to admit. - Assuming AMBR caps everything.
Session-AMBR/UE-AMBRbound only Non-GBR traffic; GBR flows are policed solely byGFBR/MFBR. Adding GBR flows does not eat into the AMBR budget. - Expecting one DRB per flow. SDAP allows N:1 mapping. If you debug per-flow behaviour by watching a DRB, remember several QFIs may share it, and reflective QoS may have created the mapping without any explicit RRC signalling.
- Forgetting the QFI is 6 bits. Only 64 QoS flows (0–63) exist per PDU session; running out is a real design constraint on flow-heavy deployments.
Contrast with LTE bearer-level QoS
The cleanest way to understand 5G QoS is to see what it replaced. In LTE the unit of QoS was the EPS bearer: one bearer carried exactly one QCI and one ARP, and it was pinned end-to-end to a dedicated radio bearer. To give a UE a new treatment you had to set up a new dedicated bearer, all the way through S-GW and P-GW. 5G breaks that rigidity by moving QoS off the bearer and onto the flow.
LTE ↔ NR: LTE = one QCI per EPS bearer, pinned 1:1 to a radio bearer; a new treatment needs a new dedicated bearer end-to-end. NR = one 5QI per QoS flow, with SDAP mapping many flows onto one DRB; a new treatment is just a new flow inside the existing PDU session. The 5QI values are a deliberate superset of QCI, and ARP carries over almost unchanged — but the Delay-critical GBR resource type and its MDBV are new in NR with no LTE equivalent.
| Aspect | LTE (bearer-level) | 5G NR (flow-level) |
|---|---|---|
| Finest QoS unit | EPS bearer | QoS flow (QFI) |
| QoS identifier | QCI (scalar) | 5QI (scalar, superset of QCI values) |
| Flow ↔ radio bearer | 1:1 (bearer = radio bearer) | N:1 via SDAP (many flows per DRB) |
| Adding a treatment | New dedicated bearer end-to-end | New flow inside existing PDU session |
| UL classification hint | TFT / uplink packet filters | QoS rules, incl. reflective QoS |
| Aggregate limits | APN-AMBR, UE-AMBR | Session-AMBR, UE-AMBR |
Two consequences matter most. First, the standardized 5QI values are a deliberate superset of the LTE QCI values — 5QI 1, 2, 5 and 9 line up with the familiar QCI 1, 2, 5 and 9 — which makes interworking and handover between EPC and 5GC straightforward. Second, the extra Delay-critical GBR resource type and its MDBV parameter simply had no equivalent in LTE; they exist because URLLC needs a hard per-burst deadline that a plain GBR bearer could not express. The ARP semantics, by contrast, carry over almost unchanged — the same priority-level plus pre-emption capability and vulnerability triad.
Summary
The 5G QoS model rests on a single object. A QoS flow, identified by a 6-bit QFI (0–63) inside a PDU session, is the finest unit of differentiated treatment. Each flow references a 5QI that resolves to standardized characteristics — Resource Type, Priority Level, PDB, PER, and for GBR/delay-critical flows an Averaging Window and MDBV — plus a separate ARP that governs admission and pre-emption rather than forwarding.
The rates split cleanly: per-flow GFBR/MFBR for GBR flows, and aggregate Session-AMBR/UE-AMBR for Non-GBR traffic only. One PCC policy from the PCF becomes three enforcement objects via the SMF — a QoS profile to the gNB over NGAP, QoS rules to the UE over NAS, and PDR/QER to the UPF over N4 — and SDAP in the gNB maps each flow onto a DRB, one-to-one or many-to-one.
The practical mental model: PDU session ⊃ QoS flow (QFI/5QI/ARP) → SDAP → DRB → PDCP/RLC/MAC. If you can name where a flow's QFI is set, which 5QI characteristics it carries, and which DRB SDAP put it on, you can reason about how any packet will be treated end-to-end.
Q. What is the finest granularity of QoS in 5G, and how is it identified?
A. The QoS flow. It is identified by the QFI (6-bit, 0–63), unique within a PDU session, and carried in the SDAP header on the radio side and in the GTP-U encapsulation header on N3 in the core.
Q. What does a 5QI define, and what does it deliberately not include?
A. A 5QI resolves to Resource Type, Priority Level, PDB, PER, an Averaging Window, and (for delay-critical) MDBV. It does not include ARP — allocation/retention priority is a separate per-flow attribute governing admission and pre-emption.
Q. Difference between Session-AMBR and UE-AMBR?
A. Both cap only Non-GBR traffic. Session-AMBR limits the aggregate of Non-GBR flows within one PDU session (policed by the UPF downlink and the UE uplink); UE-AMBR limits the aggregate across all the UE's Non-GBR flows and is enforced by the gNB.
Q. How does the QoS profile reach the gNB, and what is its counterpart at the UE and UPF?
A. The SMF sends the QoS profile to the gNB over NGAP (via the AMF, in PDU Session Resource Setup). The UE gets QoS rules over NAS for uplink classification; the UPF gets PDR/QER over N4 for downlink classification, marking and rate enforcement.
Q. How does 5G flow-level QoS differ from LTE bearer-level QoS?
A. LTE pinned one QCI to one EPS bearer mapped 1:1 to a radio bearer; changing treatment meant a new bearer. 5G puts QoS on the flow (QFI/5QI) and lets SDAP map many flows onto one DRB, so new treatments are new flows inside the same PDU session.
Quick LTE 4G / 5G NR Interview Questions — GBR Admission
Q. What happens if a PDU Session's QoS Flow requests a GBR level the network can't actually sustain right now?
A. The SMF/PCF, during QoS Flow establishment, can reject or downgrade the request based on real-time admission control — either not establishing that particular GBR flow (falling back to best-effort/default flow) or establishing it at a lower guaranteed rate, rather than accepting a QoS commitment the network can't uphold under current load.
Where this connects
QoS flows are only half the story — the other half is how they ride the radio and how the mapping is signalled. Follow the packet down the stack: