Scheduling (Dynamic & Semi-Persistent) in LTE 4G

Introduction

Scheduling is the eNB's per-subframe decision about who transmits or receives, and on which resource blocks. It is the beating heart of the MAC layer: every byte a UE ever sends or receives on the shared channels (PUSCH uplink, PDSCH downlink) arrives because the scheduler issued a grant or an assignment, carried as Downlink Control Information (DCI) on the PDCCH. The signalling is standardised in TS 36.321 and TS 36.213; the decision policy is deliberately left to the vendor.

You see the scheduler at work continuously from the moment a UE reaches RRC_CONNECTED: it runs the uplink SR→grant→BSR→grant handshake, arms semi-persistent patterns for VoLTE, folds in channel quality (CQI) and QoS (QCI), and hands each transmission to HARQ. When throughput is poor, when a UE cannot get an uplink grant, or when latency spikes, the scheduler and its feeder signals are almost always where the answer lives.

Because scheduling is really two separable questions — how a grant is delivered (dynamic DCI vs SPS) and which UE is chosen (the algorithm) — most scheduling problems localise cleanly: a missing DCI, a mis-scrambled RNTI, an SPS activation not recognised, a BSR that never arrived, or a fairness policy starving the cell edge. This page walks each of those in order.

Why scheduling is needed

Concretely, spectrum is scarce and shared, and the two directions have opposite information problems. On the downlink the eNB already holds the data in its own buffers, so it can decide allocations directly. On the uplink the data sits inside the UE and the eNB is blind to it — so it must first be asked (a Scheduling Request), then told how much there is (a Buffer Status Report), before it can size a grant. Per-TTI scheduling lets the eNB chase channel quality, fairness and QoS in real time; but spending a DCI on every tiny periodic packet is wasteful, so LTE also offers a grant-free pattern (SPS) for predictable traffic like voice.

What Scheduling Is

The eNB owns the LTE air interface. Its MAC scheduler maps buffered data — yours and every other UE's — onto the shared time/frequency grid, one Transmission Time Interval (TTI) at a time. In LTE a TTI is fixed at 1 ms (one subframe), and the frequency axis is divided into resource blocks of 12 subcarriers × 180 kHz. Downlink and uplink are handled separately because the constraints differ: on the downlink the eNB already holds the data in its buffers, while on the uplink the data sits in the UE and the eNB must first grant permission to send before anything can arrive.

Two things sit underneath every scheduling decision. First, the eNB must know each UE's channel quality — the downlink Channel Quality Indicator (CQI) the UE reports lets the scheduler pick both who to serve and the modulation-and-coding scheme (MCS) to serve them at; this is the link between scheduling and link adaptation. Second, the eNB must respect each bearer's quality of service — the QoS Class Identifier (QCI) attached to a bearer sets its priority, delay budget and whether it is guaranteed-bit-rate. A good scheduler folds both into its per-TTI choice, which is why the later algorithm families matter so much.

Dynamic Scheduling — a DCI every TTI

Dynamic scheduling is the default and most flexible mode. For each transmission the eNB sends a DCI on the PDCCH, whose CRC is scrambled (masked) with the UE's C-RNTI so only that UE acts on it. The UE blindly decodes candidates in its search space, finds a DCI whose CRC unmasks with its C-RNTI, and reads the allocation. There is no dedicated "here is your grant" channel — the addressing is the CRC mask, which is why RNTIs are central to everything the scheduler does.

Different DCI formats do the scheduling work, split by direction and by transmission mode:

A DL assignment tells the UE which resource blocks carry its PDSCH, plus the MCS, HARQ process number, redundancy version, and the PUCCH resource for its HARQ-ACK. An UL grant tells the UE where and how to send its PUSCH, including the MCS and any frequency hopping. Every scheduled transmission ties into HARQ — the DCI names the HARQ process and redundancy version so retransmissions can be soft-combined at the receiver. On the uplink LTE uses synchronous HARQ, so a retransmission lands a fixed 8 ms after the original; on the downlink HARQ is asynchronous, so the eNB retransmits whenever the scheduler finds room.

Semi-Persistent Scheduling (SPS) — periodic allocation for VoLTE

SPS is LTE's grant-free mechanism, and it works in both directions. Instead of a DCI per transmission, RRC provisions a periodic allocation via sps-Config, and a single DCI activates or releases it. The classic use case is VoLTE: an AMR speech codec emits one small packet every 20 ms, and spending a PDCCH DCI on each of those, for every voice user in the cell, would drown the control region.

The activation and release DCIs are recognised by special validation field values — for example the New Data Indicator set to 0 and certain resource/MCS fields set to defined patterns per TS 36.213 — so the UE can tell an SPS command apart from an ordinary assignment. A release is signalled the same way, with its own reserved field pattern, which is why the eNB does not need a separate message to tear the pattern down.

Downlink vs uplink SPS. The two directions share the mechanism but differ in the fine print. Downlink SPS delivers a repeating PDSCH; the UE still returns HARQ-ACK for each occasion, and the number of configured SPS HARQ processes is set by numberOfConfSPS-Processes. Uplink SPS delivers a repeating PUSCH; it adds an implicit release rule — after a configured number of consecutive empty transmissions (implicitReleaseAfter, e.g. 2, 3, 4 or 8 zero-MAC-SDU PDUs), the UE releases the pattern on its own, so an idle talk-spurt does not keep burning uplink resource. HARQ still applies to each SPS transmission, and a normal dynamic DCI addressed by C-RNTI can always override or add to an SPS occasion when extra data appears — the dynamic grant simply takes precedence for that subframe.

How Uplink Data Gets Scheduled — SR → Grant → BSR → Grant

Dynamic uplink is the interesting case, because the eNB cannot see inside the UE's buffers. The UE has to ask. The sequence is a short handshake:

1. Scheduling Request (SR). Data arrives in the UE's buffer but it has no valid UL grant. It sends a 1-bit SR on its configured PUCCH resource — essentially "I have something to send." 2. Small grant. The eNB responds with a small UL grant (DCI 0 on PDCCH) just large enough to carry a report. 3. Buffer Status Report (BSR). The UE uses that grant to send a BSR MAC control element reporting how much data it has buffered, per Logical Channel Group. 4. Right-sized grant. Now the eNB knows the volume and QoS and issues an appropriately sized grant. 5. Data on PUSCH. The UE transmits the actual data, often alongside a Power Headroom Report (PHR) so the eNB learns how much transmit power the UE has left. If the UE already holds a valid grant when data arrives, it skips the SR and sends the BSR directly. If it has data but no SR resource configured, it falls back to random access on PRACH.

SPS short-circuits this loop for VoLTE: with a periodic uplink allocation already in hand, the UE transmits its speech packet immediately — no SR, no waiting for a grant. That saved round-trip is exactly why SPS lowers voice latency, not just PDCCH load.

Reading the uplink scheduling loop in the logs

The handshake is visible as a short, ordered sequence of MAC events: an SR on PUCCH, a small DCI 0 grant, a BSR MAC CE reporting per-LCG volume, then a right-sized grant and the data (often with a PHR). The fields to line up are the C-RNTI, the reported buffer size, and the grant size that answers it.

Representative eNB MAC scheduler log — illustrative, values vary by vendor/build:

Dynamic vs Semi-Persistent

The two modes trade signalling overhead against flexibility. Put side by side:

Scheduler Algorithm Types — who gets the TTI?

Everything above answers how a grant is delivered (dynamic DCI or SPS). This section answers a different question: when several UEs all have data ready in the same subframe and there are not enough resource blocks for everyone, which UE does the scheduler pick? That decision is made by a scheduling algorithm running inside the eNB.

Each algorithm is really just a rule for computing a priority metric per UE every TTI; the scheduler serves the UE(s) with the highest metric. The three foundational families differ only in what goes into that metric:

1. Round Robin (RR) — equal turns

Trade-off: maximum fairness in turns, but low overall cell throughput because good-channel opportunities are handed to poor-channel UEs.

2. Max C/I (Maximum Rate / CQI-based) — always the best channel

Trade-off: highest cell throughput but starves cell-edge UEs — a UE in poor coverage may never be scheduled. Unfair and unusable on its own in a real network.

3. Proportional Fair (PF) — the practical middle ground

PF is what real LTE schedulers are built around. It balances the two extremes: chase good channel conditions relative to each UE's own average, so a cell-edge UE still gets served when its channel momentarily peaks. Each TTI it serves the UE with the highest ratio of instantaneous rate to its own recent average throughput:

4. Delay- and QoS-aware schedulers

Pure PF is channel-fair but blind to deadlines, so production LTE schedulers extend it to protect latency-bound and guaranteed-bit-rate bearers. These fold each packet's head-of-line delay and the bearer's QCI priority into the metric, so a packet approaching its Packet Delay Budget, or a high-priority QCI bearer (e.g. QCI 1 for VoLTE), gets boosted before it is late.

Other / derived schedulers

Side by side

To see why they behave so differently, picture three UEs in one cell — UE₁ near the eNB (great channel), UE₂ mid-cell, UE₃ at the edge (poor channel) — all with data to send in the same subframe:

Scheduling, QoS, Link Adaptation and Coverage

The scheduler does not work in isolation — three neighbouring mechanisms feed it or lean on it, and understanding scheduling means understanding those seams.

QoS (QCI priorities). Each EPS bearer carries a QCI that fixes its priority level, Packet Delay Budget and whether it is Guaranteed Bit Rate. QCI 1, for instance, is the conversational-voice bearer used by VoLTE — low delay budget, high priority. The scheduler reads these values when it weights its per-TTI metric, so a high-priority or near-deadline bearer is served ahead of best-effort traffic. This is the bridge between the abstract QoS the core network promises and the concrete resource blocks the eNB hands out.

CQI-driven link adaptation. Once the scheduler has chosen a UE, it must choose how fast to send. The UE's reported CQI maps to an MCS and therefore a transport-block size: a strong channel earns 64-QAM (or 256-QAM in later releases) at a high code rate, a weak channel drops to QPSK. Scheduling picks who; link adaptation picks how fast — and both read the same CQI, which is why channel-aware schedulers get link adaptation "for free."

TTI bundling for coverage. When a cell-edge UE cannot close the uplink budget even at the lowest MCS, a single 1 ms transmission may not carry enough energy. TTI bundling lets the UE send the same transport block across a bundle of consecutive subframes (four in LTE), HARQ-combined at the eNB, with a single grant covering the whole bundle. It trades peak rate for reliable coverage — a coverage tool the scheduler reaches for at the cell edge, and a close cousin of the delay-aware policies above.

Summary

Scheduling is the eNB deciding, every 1 ms TTI, who transmits or receives and on which resource blocks — delivered as a DCI on PDCCH, addressed by a CRC scramble (C-RNTI for dynamic, SPS-C-RNTI for semi-persistent, and the broadcast RNTIs SI-RNTI/P-RNTI/RA-RNTI in the common search space). Split the topic in two: how the grant is delivered (dynamic DCI vs SPS) and which UE is chosen (RR / Max C/I / PF / QoS-aware, all vendor policy).

On the uplink the eNB is blind to the UE's buffer, so the SR→grant→BSR→grant handshake exists to discover volume before sizing a grant; SPS short-circuits it for periodic VoLTE traffic. To debug, walk the delivery path first — is the DCI decoded (right RNTI, right search space, PDCCH capacity)? — then the feeder signals (SR resource, BSR volume, PHR headroom), then the policy (is the cell edge being starved?). Almost every "no throughput" or "no uplink grant" ticket resolves at one of those points.

Finally, scheduling never stands alone: QCI tells it how important a bearer is, CQI tells it how good the channel is (and sets the MCS via link adaptation), HARQ closes each transmission, and TTI bundling rescues the cell edge. The scheduling algorithm is where all of these meet, every millisecond.