GBR vs Non-GBR
Every QoS flow in 5G is one of two resource types, and that choice decides whether the network reserves bandwidth for it. A GBR (Guaranteed Bit Rate) flow gets a reserved rate — the GFBR is the minimum the network commits to, the MFBR the ceiling it will police to. That reservation goes through admission control, so a GBR flow can be refused at setup if the cell has nothing left, but once it's up it's protected. This is what real-time traffic needs: voice, conversational video, anything that falls apart when it's starved.
A Non-GBR flow reserves nothing. It rides the capacity left over after the GBR flows are served, best-effort, with the total capped only by an AMBR the UE or session shares across all its Non-GBR flows. That suits elastic data — web, app traffic, email — where a slower moment is fine. The split shows up in the 5QI table too: GBR 5QIs like 1, 2, 3, 4 (plus delay-critical-GBR values), and Non-GBR ones like 5, 6, 7, 8, 9.
| Aspect | GBR | Non-GBR |
|---|---|---|
| Bandwidth guarantee | Yes — a GFBR is reserved per flow, policed up to the MFBR | None — no committed rate, takes whatever is spare |
| Admission control | Yes — the flow can be refused at setup if resources are short | No — set up without reserving radio resources |
| Example 5QIs | 1, 2, 3, 4 (standardised GBR), plus delay-critical GBR values | 5, 6, 7, 8, 9 (9 is the common default) |
| Example services | VoNR voice, conversational video, real-time gaming, V2X | Web, email, app data, file transfer, video streaming buffer |
| Rate limiting | Per flow — the MFBR caps each GBR flow on its own | Aggregate — Session-AMBR per PDU session, UE-AMBR across the UE |
| Under congestion | Protected once admitted; may be blocked at setup instead | Throttled down — the leftover capacity just shrinks |
| Counts against AMBR? | No — GBR flows sit outside the AMBR budget | Yes — all Non-GBR flows share the Session- and UE-AMBR |
| Resource Type field | GBR, or Delay-critical GBR | Non-GBR |
| Extra GBR-only parameters | GFBR, MFBR, and (for delay-critical) a Maximum Data Burst Volume | None of these — only priority, delay, and error targets apply |
| Typical PDB / PER | Tight, single packet-level targets (e.g. ~100 ms or lower; low PER) | Looser, elastic targets (e.g. ~300 ms for the 5QI 9 default) |
| Replaces (vs 4G) | The LTE GBR dedicated bearer | The LTE default / non-GBR bearer |
What 'guaranteed' actually means (GFBR and MFBR)
For a GBR flow the network signals two rates. The GFBR (Guaranteed Flow Bit Rate) is the floor — the rate the network commits to deliver under normal conditions. The MFBR (Maximum Flow Bit Rate) is the ceiling — traffic above it is dropped or delayed rather than carried. Both are signalled per direction (uplink and downlink can differ).
"Guaranteed" here means reserved, not infallible. The gNB runs admission control against the GFBR: if the cell can't fit another flow at its guaranteed rate, the request is rejected, which is why a voice call can fail to set up in a congested cell. But a flow that is admitted has its share held for it, so a later burst of best-effort traffic can't squeeze it. The MFBR exists so one flow can't grab more than its design rate and starve the others — useful for both policing and planning how many flows a cell can hold.
How Non-GBR shares the leftovers (AMBR)
Non-GBR flows don't reserve anything, so they share whatever capacity the GBR flows haven't claimed. There's no per-flow guarantee and no per-flow rate cap. Instead the limit is an aggregate: the Session-AMBR caps the sum of all Non-GBR flows in one PDU session, and the UE-AMBR caps the sum across the device. The UE-AMBR comes from subscription data (held in the UDM, enforced by the SMF and gNB); the Session-AMBR is set per PDU session and can be tuned by policy.
Because the cap is shared, Non-GBR throughput moves with load. On a quiet cell a single Non-GBR flow may run close to the AMBR; on a busy one it drops back as the scheduler spreads what's left. That elasticity is exactly the point — web pages, downloads, and app traffic cope fine with a variable rate, so there's no reason to lock bandwidth away for them. The default flow in most PDU sessions is Non-GBR, usually 5QI 9.
Delay-critical GBR for URLLC
Standard GBR was built for steady streams like voice. URLLC traffic is different: short, bursty packets that must arrive inside a hard deadline. 3GPP added a third resource type, Delay-critical GBR, for this.
It keeps the GBR reservation and admission control, but adds a Maximum Data Burst Volume (MDBV) — the largest chunk of data the network must move within the packet delay budget — and ties the packet delay budget to the radio interface more strictly. The packet error rate target is also tighter, reflecting the reliability these flows need. So you can think of three buckets, not two: GBR for real-time streams, Delay-critical GBR for URLLC bursts, and Non-GBR for everything elastic. All three are just values of the same Resource Type field that hangs off the 5QI.
The bottom line
Use GBR for traffic that breaks when it's starved — VoNR voice, conversational video, real-time gaming, and (as Delay-critical GBR) URLLC bursts. The reserved GFBR and the admission check are worth the cost of a call occasionally being blocked at setup, because once it's up the rate is protected. Use Non-GBR for everything elastic — web, app data, email, file transfer, streaming — where a variable rate under the AMBR is fine and there's no reason to lock resources away. As a rule of thumb: if a slow second ruins the experience, make it GBR; if the app just waits a moment longer, leave it Non-GBR.
Frequently asked questions
- What's the difference between GBR and Non-GBR?
- A GBR (Guaranteed Bit Rate) flow has bandwidth reserved for it — a GFBR floor and an MFBR ceiling — and goes through admission control, so it can be refused at setup but is protected once active. A Non-GBR flow reserves nothing and runs best-effort over the spare capacity, capped only by an aggregate AMBR. GBR suits real-time traffic like voice and video; Non-GBR suits elastic data like web and app traffic.
- Is VoNR GBR or Non-GBR?
- VoNR voice runs on a GBR flow. The voice media uses 5QI 1, a standardised GBR value with a guaranteed bit rate and a tight delay budget, so the network reserves capacity for the call. The IMS SIP signalling, by contrast, rides a Non-GBR flow (commonly 5QI 5).
- What is GFBR vs MFBR?
- Both apply only to GBR flows. The GFBR (Guaranteed Flow Bit Rate) is the minimum rate the network commits to deliver under normal conditions and is what admission control checks against. The MFBR (Maximum Flow Bit Rate) is the upper limit the flow is allowed to use; traffic above it is policed (dropped or delayed). Each is signalled separately for uplink and downlink.
- Does Non-GBR have any rate limit?
- Yes, but not per flow. Non-GBR flows are bounded by the AMBR — the Session-AMBR caps the sum of all Non-GBR flows in a PDU session, and the UE-AMBR caps the total across the device. There's no guaranteed minimum and no per-flow ceiling, so each flow's actual rate floats with how busy the cell is.
- What is Delay-critical GBR?
- Delay-critical GBR is a third resource type, alongside GBR and Non-GBR, aimed at URLLC. It keeps the reservation and admission control of GBR but adds a Maximum Data Burst Volume and a tighter, radio-bound delay target for short, bursty traffic that must meet a hard deadline — for example factory control or V2X.
Related terms
Go deeper than GBR vs Non-GBR — free for 7 days.
Learn GBR vs Non-GBR and the full 5G/6G stack with interactive lessons, labs and a TelcoMentor AI coach. Start a free 7-day Pro trial — no credit card.
- No credit card
- Full Pro access
- 21 verifiable certs
- TELCOMA since 2009
Get weekly 5G/LTE engineering deep-dives
One technical breakdown every Tuesday — plus first access to new tools and lessons. No spam, no marketing, just engineering. Unsubscribe in one click.