5G Scheduling Algorithms: Round Robin, Proportional Fair, and What Real Schedulers Do

The MAC scheduler is the single most important piece of unspecified software in a 5G network.

3GPP defines the resource grid, the signalling that conveys an allocation, and the QoS parameters describing what each flow needs. It does not define how the gNB decides who gets what. That decision runs every slot — every 500 microseconds at 30 kHz subcarrier spacing — and it's where vendors genuinely differentiate.

Understanding the classic algorithms is worthwhile not because anyone deploys them unmodified, but because every production scheduler is recognisably built from these ideas.

---

The decision being made

Each slot, the scheduler picks which UEs to serve, how many resource blocks each gets, which MCS to use, and how to layer that across MIMO streams and component carriers.

Its inputs:

Channel quality — CQI reports downlink, sounding reference signals uplink. Determines the achievable rate per resource block.

Buffer status — how much data is waiting. Downlink the gNB knows directly; uplink it depends on Buffer Status Reports from the UE.

QoS parameters — 5QI priority, delay budget, GBR commitments.

Packet delay — how long data has already been queued against its budget.

HARQ state — pending retransmissions typically take precedence over new transmissions.

Power headroom — uplink only, and often the binding constraint at cell edge.

The reason this is hard is that the same resource blocks yield wildly different throughput depending on who receives them:

A UE near the cell centre might get 6 bits per resource element at 256QAM. A cell-edge UE on QPSK gets 2. Give both the same allocation and one produces three times the data. Fairness in resources and fairness in throughput are not the same thing, and choosing between them is essentially what a scheduling algorithm is.

---

Round Robin

Serve each UE in turn, equal resources, ignore the channel.

Simple, predictable, starvation-free, and a useful baseline for measuring anything else. It's also poor in practice.

Because it ignores channel conditions, it allocates resources to a UE in deep fade at exactly the moment those resources produce the least data. Cell throughput suffers, and the UEs it was trying to be fair to don't even get equal throughput — just equal resources.

Round Robin appears in real systems only as a tie-breaker within a priority class, never as the top-level policy.

---

Maximum rate

The opposite extreme: always serve the UE with the best instantaneous channel.

Maximises cell throughput and is unusable. A UE with persistently poor conditions — indoors, at the edge — is never scheduled at all. Total starvation for a substantial fraction of users.

Useful only as the other end of the spectrum. The real question is what sits between.

---

Proportional Fair

The answer that became the industry default. For each UE, compute:

        R_i(t)
M_i  =  ──────
        T_i(t)

Where R_i(t) is the instantaneous achievable rate right now, and T_i(t) is that UE's average throughput over a sliding window. Schedule the highest metric.

The elegance is in the ratio. The numerator rewards good current conditions; the denominator penalises UEs that have already been served well. A UE with a persistently mediocre channel accumulates low average throughput, its denominator shrinks, and eventually its metric wins despite modest instantaneous rate.

What makes it genuinely clever is that it exploits multi-user diversity. Fading is independent across UEs, so at any given moment someone is at a peak relative to their own average. PF preferentially schedules UEs at their personal peaks — which is efficient and fair, because "peak relative to own average" doesn't systematically favour cell-centre users.

The averaging window is the tuning knob. A short window makes PF more responsive and more fair in the short term; a long window makes it more throughput-oriented. Typical values land in the hundreds of milliseconds.

PF's limitation: it knows nothing about QoS. Delay budgets, GBR commitments, and 5QI priority are all invisible to it. That's what production schedulers add.

---

QoS-aware scheduling

Real 5G schedulers are layered. A common structure:

First, retransmissions. Pending HARQ retransmissions go before new data — the receiver is already holding soft buffer contents and the combining gain is available now.

Second, GBR commitments. Flows below their guaranteed bit rate get priority until they're satisfied. This is the network keeping an admission-control promise.

Third, delay-critical traffic. Packets approaching their PDB get urgency that scales as the deadline nears. A packet at 80% of its budget outranks one that just arrived, regardless of nominal priority.

Fourth, everything else by a PF-style metric weighted by 5QI priority.

The naive approach — strict priority by 5QI — fails badly:

Under load, strict priority starves everything below the top class. Production schedulers use weighted approaches where priority biases the metric rather than dominating it absolutely.

---

Mixing URLLC and eMBB

This is the hardest scheduling problem NR introduced, because the two service types want contradictory things.

eMBB wants large transport blocks, aggressive MCS, and full slots — throughput per unit of spectrum. URLLC wants immediate transmission, conservative MCS, and bounded latency. It'll happily waste spectrum to hit a deadline.

The scheduling gap is the core difficulty. A URLLC packet arriving mid-slot can't wait for the next slot boundary if its budget is 1 ms and the slot is 500 µs — that's most of the budget gone before transmission even starts.

NR's answer is preemption:

The scheduler allocates URLLC data onto resources already assigned to an ongoing eMBB transmission, then signals the affected UE with a preemption indication (DCI format 2_1). The eMBB UE learns which resources were overwritten and excludes them from soft combining, so its HARQ retransmission still works correctly rather than combining corrupted data.

Supporting mechanisms:

Mini-slots let transmission start at any symbol rather than waiting for a slot boundary.

Configured grants give the UE pre-allocated uplink resources, removing the scheduling request round trip entirely — one of the largest latency components in uplink URLLC.

Separate MCS tables let URLLC use a low-spectral-efficiency, high-reliability table targeting 10⁻⁵ BLER rather than eMBB's 10⁻¹.

The cost is real. Every preempted eMBB transmission wastes resources. Every configured grant reserves capacity that may go unused. URLLC capacity is expensive, and network planning has to account for it explicitly rather than assuming it comes free with the feature.

---

Link adaptation is the loop underneath scheduling

Choosing which UE to serve is only half the decision. The other half is choosing how aggressively to transmit to it, and that runs as a control loop rather than a calculation.

The inner loop starts with the CQI the device reports. But CQI is a hypothesis about a moment already past, measured on reference signals under assumptions that may not hold when the grant is actually transmitted. Interference in particular is not predictable from a past measurement — a neighbouring cell may schedule a burst in exactly the slot being planned for.

So the outer loop corrects for systematic error. The scheduler maintains a per-UE offset applied to the reported CQI, adjusted by HARQ outcomes: a NACK pushes the offset down, a run of ACKs lets it drift up. The loop converges on whatever offset produces the target first-transmission BLER, conventionally 10%.

That 10% target is not a compromise with failure — it is the optimum. Targeting 1% would mean transmitting so conservatively that most blocks carry far less data than the channel allowed. Targeting 30% would waste capacity on retransmissions. Ten percent is roughly where the throughput curve peaks, given that HARQ makes retransmissions cheap.

Why the scheduler cannot simply trust CQI

Three effects push reported CQI away from reality, and a production scheduler compensates for all of them:

Ageing. By the time a grant is transmitted, the report describes a channel several slots old. At vehicular speeds the channel has changed materially.

Quantisation. CQI is a four-bit index into a table. The real channel sits between table entries.

Interference mismatch. The device measured interference during the reference signal occasion. Actual interference during the data transmission depends on what neighbouring cells decided to do.

This is why two schedulers with identical algorithms and identical inputs produce different throughput. The algorithm is standardised in the textbooks; the correction loops are not, and they are where vendor differentiation actually lives.

---

Uplink is a different problem

Downlink scheduling is comparatively easy: the gNB has the data, knows the buffer, and measures the channel from CQI reports.

Uplink introduces three complications:

The gNB doesn't know the buffer. It depends on Buffer Status Reports, which are periodic and therefore stale.

Grant latency. A UE with new data sends a scheduling request, waits for a grant, then transmits. That round trip is pure latency — and why configured grants matter for URLLC.

Power limitations. Cell-edge UEs are power-limited, so allocating more resource blocks spreads fixed power more thinly and reduces per-RB SNR. The scheduler must sometimes allocate fewer RBs to a distant UE to keep them decodable — a constraint with no downlink equivalent.

Uplink also uses SRS rather than CQI for channel knowledge, and in TDD can exploit channel reciprocity to infer uplink conditions from downlink measurements.

---

What production schedulers actually look like

A commercial gNB scheduler is not a textbook algorithm. It's a weighted multi-objective optimiser handling several hundred UEs per cell, running per slot, with hard real-time deadlines, coordinating across carriers, MIMO layers, and beams.

Additional realities: inter-cell coordination, so scheduling decisions account for interference to neighbours. Link adaptation coupling, where MCS selection and resource allocation are decided jointly. Multi-user MIMO pairing, choosing which UEs can share resources on separate spatial layers. Slice-aware allocation, respecting per-slice resource commitments.

And increasingly, learned components — the point where scheduling meets AI-RAN, since scheduling is a high-dimensional decision problem with abundant training data.

---

Buffer status and the uplink chicken-and-egg

The uplink has a structural problem the downlink does not: the data is in the device, and the scheduler is in the network. The gNB cannot see the buffer it is scheduling for.

Buffer Status Reports close the loop, but they are less precise than they appear. A BSR reports buffered volume per logical channel group, not per logical channel — typically four groups covering all bearers. A device with voice and a background download in the same group reports one aggregate figure, and the scheduler cannot tell them apart from the report alone.

BSRs are also quantised into an index into a table with coarse steps at high volumes, and they are triggered rather than continuous: on new data of higher priority, on a periodic timer, or on padding availability.

Which produces the bootstrapping problem. A device with data and no grant cannot send a BSR, because sending anything requires a grant. It must use scheduling request on PUCCH — a single bit meaning "I have something" with no indication of what or how much. The network responds with a small grant, the device uses it to send a proper BSR, and only then does real scheduling begin.

That sequence costs a round trip before any data moves, which is why configured grants exist for latency-sensitive uplink traffic: resources allocated in advance, so the device transmits without asking.

---

Fairness over what, exactly

Proportional Fair is described as balancing throughput and fairness, but fairness needs a subject, and the choice of subject changes the outcome substantially.

Per-UE fairness is the classic formulation. Each device gets a comparable share of the metric. A device running ten flows gets the same total as a device running one.

Per-bearer or per-flow fairness divides the resource among flows instead. Now the device with ten flows receives ten shares — arguably fairer to applications, arguably unfair to users.

Per-slice fairness operates a level higher again, dividing capacity between slices before dividing within them.

Real schedulers operate several of these simultaneously in a hierarchy: slice weights at the top, then per-UE fairness, then per-bearer priority within the UE. Each level has its own state and its own time constant.

There is also the question of what is being averaged. The PF metric divides instantaneous rate by historical throughput, and the averaging window for that history is a tuning parameter with real consequences. A short window makes the scheduler responsive but jittery. A long window is smooth but slow to react — a device emerging from a tunnel is treated as well-served long after its channel has collapsed.

---

The mental model

3GPP specifies the parameters, not the algorithm. Scheduling is where vendors compete.

Equal resources ≠ equal throughput. Choosing between them is what the algorithm does.

Proportional Fair = instantaneous rate ÷ average throughput. It exploits multi-user diversity, which is why it's both efficient and fair.

Production schedulers layer retransmissions → GBR → delay-critical → weighted PF.

URLLC preempts eMBB, and DCI 2_1 tells the victim which resources to exclude from combining.

Uplink is harder: stale buffer knowledge, grant latency, and power-limited UEs.

If you take one thing: the scheduler is where every abstraction above it — QoS profiles, slice commitments, service level agreements — either becomes real or quietly doesn't.

---

Further reading

• 3GPP TS 38.321 — MAC specification, scheduling procedures and buffer status reporting
• 3GPP TS 38.214 — Physical layer procedures for data, MCS tables and resource allocation
• 3GPP TS 38.213 — Physical layer procedures for control, preemption indication
• 3GPP TS 23.501 — QoS model and 5QI characteristics