5G MAC Scheduling Explained in 10 Minutes

Every half millisecond, in every cell, a piece of software decides who transmits and what they transmit. Nothing above it works if it gets that wrong, and nothing below it happens until it has decided.

That software is the MAC scheduler, and it is worth ten minutes even if you never touch one — because most of the parameters people argue about in a network are inputs to it.

---

What MAC actually owns

The layer is smaller than its reputation suggests. Four responsibilities, and it is useful to know what is not on the list.

Mapping and multiplexing. MAC takes data from logical channels — which are defined by what the data is: signalling radio bearers, each data radio bearer — and packs it into a transport block, which is defined by what the physical layer can carry this slot. That translation is the layer's core job.

HARQ. The retransmission entity lives here, with up to sixteen parallel processes per carrier in each direction. How the combining works is a physical-layer story; deciding when to retransmit is MAC's.

Scheduling and priority handling. Which UE gets resources, and how much.

Reporting. Buffer status and power headroom on the uplink, so the network can schedule a device it cannot see inside.

What MAC does not do: channel coding and rate matching (physical layer), segmentation and reordering (RLC), ciphering and duplicate detection (PDCP). If you find yourself explaining a MAC problem in terms of encryption, you are one layer off.

The five decisions

Every scheduling opportunity, the same five questions are answered in order.

Who. Which UEs are eligible — they have data, they are in sync, they have a valid configuration for this slot, and their HARQ state permits a new transmission.

How much. How many resource blocks each one gets.

How hard. Which modulation and coding scheme, derived from the reported CQI and corrected by an outer loop that the standard does not describe.

Where. Which MIMO layers, which antenna ports, which beam.

What. Which logical channels' data actually fills the transport block that resulted.

The first four are where vendors compete — the algorithms behind them are unspecified on purpose. The fifth is specified exactly, and it is the one most people have never read.

Logical channel prioritisation

A grant arrives. The UE now has a transport block of fixed size and several bearers with data waiting. Which bearer's bytes go in?

Strict priority is the obvious answer and it is the wrong one: the highest-priority channel would take the whole grant every time, and a lower-priority bearer behind a busy one would never move. So NR uses two rounds.

Round one is bounded. Each logical channel is configured with a prioritised bit rate and a bucket size duration. Between grants, a token bucket for that channel fills at the prioritised bit rate and is capped at the rate multiplied by the duration. In round one, channels are served in decreasing priority order, but each one only up to the tokens it has accumulated.

Round two is not. Whatever space is left is filled in strict priority order until the grant or the data runs out.

The structure gives every configured bearer a rate guarantee rather than a share guarantee, which is the right shape for the problem: a background bearer should keep trickling under load, not claim a fixed fraction of a grant it does not need.

Setting a prioritised bit rate to infinity is how you say "this channel takes everything it can" — which is exactly what signalling radio bearers are configured to do, and exactly what a data bearer should not be.

The restrictions are the NR addition

LTE had this mechanism. What NR adds is that a logical channel can be restricted to particular kinds of grant: an allowed subcarrier spacing, a maximum PUSCH duration, whether a configured grant may carry it, which serving cells are permitted.

This exists because of mixed numerologies. A latency-critical bearer must not have its data placed in a long, low-subcarrier-spacing transmission that will still be in the air when its budget expires — and without the restrictions, LCP would cheerfully do exactly that, because it only knows about priority and rate. Most URLLC bearer misconfiguration lives in these four fields, not in the QoS profile.

The uplink problem

Downlink scheduling is comparatively easy. The gNB holds the data, so it knows the buffer exactly, and CSI reports tell it the channel.

The uplink inverts both. The data is in the device and the scheduler is in the network, which produces a bootstrapping problem: the UE cannot report its buffer without a grant, and it will not get a grant until it has reported its buffer.

The way out is a single bit. The UE sends a scheduling request on PUCCH — it means I have something, with no indication of what or how much. The network answers with a small grant, the UE spends it on a proper buffer status report, and only then does real scheduling begin.

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

What a buffer status report actually tells you

Less than its name suggests, in three ways.

It reports per logical channel group, not per logical channel. NR allows eight groups, so the aggregation is looser than LTE's, but it is still aggregation: two bearers in the same group arrive as one number, and the scheduler cannot tell them apart from the report alone.

It is quantised into a table index, with coarse steps at high volumes. The scheduler learns the order of magnitude, not the byte count.

It is triggered, not continuous — on higher-priority data arriving, on a periodic timer, or opportunistically as padding when a grant has spare room. Between triggers, the network is working from a figure that is already old.

The parts that bite

Scheduling request periodicity is a latency floor. A UE with a 10 ms SR period waits an average of 5 ms before it can even ask. Nothing downstream recovers that. Shorten it and you consume uplink control resource on every configured UE whether or not they have anything to say — which is why this parameter is argued about more than any other in a latency-sensitive deployment.

Grants that are too small produce loops. If the grant cannot fit the buffered data plus the report describing it, the UE spends the grant, reports again, and waits for another. A cell showing many small uplink grants per data transfer usually has an initial grant sized for the scheduling request rather than for the traffic.

Retransmissions outrank everything. A pending HARQ retransmission normally takes the resource before any new transmission, because the soft buffer is already holding the earlier copy and the combining gain is available now. This is correct behaviour that looks like unfairness in a counter.

Priority is not the same as urgency. LCP orders bearers by configured priority. It has no idea how long a packet has been queued. Deadline awareness lives in the network's scheduler, not in the specified part — which is why two gNBs with identical bearer configuration can behave completely differently under load.

The device decides the uplink contents. The network sizes the grant; the UE fills it. If the wrong bearer's data keeps arriving, look at the UE's logical channel configuration before looking at the scheduler.

---

The mental model

MAC translates between what data is and what the slot can carry. Logical channels in, transport blocks out.

Four decisions are the vendor's, one is the standard's. Who, how much, how hard and where are unspecified. What fills the block is specified exactly.

LCP runs twice: once bounded by each channel's token bucket, once by strict priority. Round one is what stops a busy bearer starving the rest.

The LCP restrictions are the NR-specific part, and they exist because mixed numerologies made "which grant" a question worth asking.

The uplink is scheduled blind. A scheduling request is one bit; a buffer status report is grouped, quantised and stale.

Configured grants exist to delete the round trip, not to improve throughput.

If you take one thing: almost every uplink latency complaint resolves to the scheduling request period, the initial grant size, or an LCP restriction that was never set.

Further reading

• 3GPP TS 38.321 §5.4.3 — logical channel prioritisation, and §5.4.5 for buffer status reporting
• 3GPP TS 38.321 §5.4.4 — scheduling request procedure
• 3GPP TS 38.331 — LogicalChannelConfig, BSR-Config and SchedulingRequestConfig
• 3GPP TS 38.214 — resource allocation and MCS determination for the resulting grant
• ShareTechnote's 5G handbook, for MAC PDU structures and decoded log traces