The Medium Access Control layer

1 · The job of the MAC layer

The 5G NR radio protocol stack is a stack of translators. Each layer takes the language of the layer above and rewrites it for the layer below. The Service Data Adaptation Protocol speaks of QoS flows; the Packet Data Convergence Protocol speaks of secured, ordered packets; the Radio Link Control layer speaks of segments and retransmissions. The Medium Access Control layer — MAC — speaks the language closest to the radio itself: transport blocks, scheduled onto real time-frequency resources, in real slots.

MAC sits as the lower half of Layer 2, between RLC above and the physical layer below. Its position is not an accident. It is the precise boundary between the logical world, where data is organised by radio bearer and purpose, and the physical world, where there is only one shared medium and a finite number of resource blocks per slot. Somebody has to decide how the logical maps onto the physical, instant by instant. That somebody is MAC.

The services MAC offers to RLC are deceptively short to state: data transfer, and radio-resource allocation. But underneath those two phrases live every procedure in this book. To deliver data, MAC must multiplex many logical channels into one transport block, correct errors with retransmissions, and respect the relative priority of each flow. To allocate radio resources, it must get the device onto the air in the first place, keep its uplink time-aligned, ask the network for grants, and report how much data and how much power the device has.

It is equally important to know what MAC does not do. It does not cipher or protect integrity — that is PDCP. It does not segment a packet to fit a grant — that is RLC. It does not modulate, code, or map to antenna ports — that is PHY. MAC's lane is mapping, multiplexing, HARQ, reporting, and prioritising. Keeping that boundary crisp is the first skill of a protocol engineer: when something breaks, knowing which layer owns the problem cuts the search in half before you have read a single log line.

2 · The MAC entity, and how it is rebuilt

A MAC entity is the running instance of the layer for one cell group. In the simplest device — one connected to a single cell group — there is exactly one MAC entity, and everything in this book happens inside it. But 5G is rarely that simple, and the number of entities is the first thing to establish when you read a configuration.

With dual connectivity, the device runs two MAC entities at once: one for the Master Cell Group (MCG) and one for the Secondary Cell Group (SCG). They are genuinely independent — separate HARQ processes, separate timers, separate random-access state. A buffer status report on the SCG says nothing about the MCG. During a DAPS handover (Dual Active Protocol Stack), the source and target each get an entity and they run together for a brief overlap, so that data keeps flowing while the device switches cells — the near-zero-interruption trick. Sidelink adds a PC5 path inside the entity for direct device-to-device traffic.

Inside any entity is a fixed set of functional blocks: a logical-channel prioritisation and multiplexing unit, a HARQ unit (with one HARQ entity per serving cell), a random-access controller, a control-element generator, and a demultiplexer for the receive direction. These are not separate processes you can see; they are the conceptual machinery the specification describes, and naming them is how you locate a problem.

The MAC reset — a clean slate

When RRC reconfigures the device in a way that invalidates state — at handover, at re-establishment, at certain failures — it orders a MAC reset. This is one of the most important and least glamorous procedures in the layer, because so many "mystery" field issues are simply state that should have been reset and was not, or was reset at the wrong moment.

On a reset, the entity initialises every Bj token bucket to zero, stops all running timers, considers all timeAlignmentTimers expired (so the uplink is no longer aligned), sets the various counters (preamble, BSR, SR) back to their start, flushes the soft buffers of every HARQ process, and cancels any triggered-but-unsent reports. After a reset the device is, from MAC's point of view, freshly born — it must earn its way back onto the air through random access.

3 · Channels, and the great translation

There are two kinds of channel either side of MAC, and confusing them is the most common conceptual slip an engineer makes. Logical channels describe what is being carried — is it a control message, a paging message, a chunk of user traffic? Transport channels describe how it is carried over the air — with what error protection, what transport-block structure, what scheduling. MAC's defining act is to map one onto the other.

The logical channels split into control and traffic. On the control side: the Broadcast Control Channel (BCCH) for system information, the Paging Control Channel (PCCH), the Common Control Channel (CCCH) for devices without a dedicated identity yet, and the Dedicated Control Channel (DCCH) for signalling to a known device. On the traffic side: the Dedicated Traffic Channel (DTCH) for user data, plus multicast channels (MCCH/MTCH) and the sidelink channels (SCCH, STCH, SBCCH).

The transport channels are fewer, because the radio offers only a few fundamentally different ways to carry bits. Downlink has the Broadcast Channel (BCH) for the master information, the Paging Channel (PCH), and the workhorse Downlink Shared Channel (DL-SCH). Uplink has the Random Access Channel (RACH) for the preamble and the Uplink Shared Channel (UL-SCH). Sidelink has SL-SCH and SL-BCH.

Notice that the Downlink Shared Channel carries many logical channels at once — system information, signalling, and user data can ride in the very same transport block. That single observation is the entire motivation for the next two functions of MAC. Because one transport channel carries many logical channels, MAC must multiplex them on the way out and demultiplex them on the way in, and it must decide which logical channel gets the room when the grant is too small for all of them.

4 · The five things MAC actually does

Strip away the acronyms and MAC performs a short, memorable list of functions. Every procedure in the rest of this book is one of these five, examined up close.

1 · Mapping

Map logical channels onto transport channels, as the previous chapter described. This is the quiet, constant function that makes the others possible.

2 · Multiplexing and demultiplexing

On transmit, pack MAC SDUs (the data from each logical channel) and MAC control elements into a single transport block. On receive, take the transport block apart and deliver each piece to its destination. The structure that makes this reversible — the subheaders — is Chapter 8.

3 · Error correction through HARQ

Hybrid Automatic Repeat reQuest: when a transport block fails to decode, retransmit it and combine the copies. There is one HARQ entity per serving cell. HARQ is MAC-controlled but PHY-assisted — MAC keeps the process bookkeeping, while the soft combining of the received energy happens down in PHY.

4 · Scheduling-information reporting

The uplink is the device's responsibility to advocate for. The Scheduling Request (SR) says "I have something to send." The Buffer Status Report (BSR) says "this much." The Power Headroom Report (PHR) says "and I have this much power left to send it." These three small messages drive almost all uplink behaviour.

5 · Priority handling

Two flavours. Between devices, priority is handled by the scheduler in the gNB through dynamic scheduling — not in the device's MAC at all. Between the logical channels of a single device, priority is handled by Logical Channel Prioritisation (Chapter 9), which decides how a single uplink grant is divided among competing flows, with padding to fill any remainder.

5 · Random access — the front door

Before a device can be scheduled, it must be known to the cell and time-aligned to it. Random access is how that first contact is made — and how it is re-made whenever timing is lost, a handover lands, beam recovery is needed, or uplink data arrives while the device is out of sync. It is the front door of the network, and a falling random-access success rate is the first thing a network engineer learns to fear.

There are two procedures. Four-step (Type-1) random access is the classic exchange. The device picks a preamble and sends it on the RACH (Msg1). The gNB replies with a Random Access Response (Msg2) carrying a timing-advance command, an uplink grant, and a temporary identity. The device transmits its first real uplink message on that grant (Msg3), and the gNB resolves any contention — because several devices may have chosen the same preamble — by echoing back an identifier (Msg4). Only the device whose identifier is echoed considers the access successful; the others back off and try again.

Two-step (Type-2) random access compresses this. The device sends MsgA — a preamble plus a small PUSCH payload — in one shot, and the gNB answers with MsgB. It is faster, and valuable in lightly loaded or small-cell deployments, but it falls back to the four-step procedure if MsgB indicates the network only received the preamble. Which procedure the device attempts can be chosen by an RSRP threshold (msgA-RSRP-Threshold): strong signal, try the fast path; weak signal, use the robust one.

Random access is also either contention-based (the device picks a preamble from a shared pool, so collisions are possible and contention resolution is needed) or contention-free (the gNB hands the device a dedicated preamble in advance — used for handover and beam recovery, where speed and certainty matter).

Power ramping — politely getting louder

If a preamble draws no response, the device assumes it was not heard and tries again, a little louder. The target receive power climbs by powerRampingStep decibels each attempt, tracked by a ramping counter — though notably the counter does not advance when the power is deliberately held constant, for example because the device switched to a different beam (a different spatial filter) rather than simply being too quiet.

The device counts its attempts. When the transmission counter passes preambleTransMax, it declares a random-access problem to RRC — the access has failed, and a higher-layer recovery (such as re-establishment) takes over. Between attempts the device waits a randomised backoff, scaled by the backoff-indicator value the network may include in the response, so that a crowd of colliding devices spreads out in time rather than colliding again in lockstep.

6 · Timing advance — keeping the uplink in step

Radio waves take time to travel, and a device at the cell edge is further from the gNB than one beneath the tower. If every device transmitted at the nominal slot boundary, their signals would arrive at the gNB smeared across time and interfere. Timing advance is the correction: each device transmits slightly early, by an amount that exactly cancels its propagation delay, so that all uplinks land aligned at the receiver.

The device first learns its timing advance from the Random Access Response, which carries an absolute value. Thereafter the network nudges it with the Timing Advance Command MAC CE, a relative adjustment. The granularity of the correction scales with the sub-carrier spacing — wider sub-carriers mean shorter symbols and a finer timing step — which is why the timing-advance formulas all carry a factor of 2 raised to the numerology index.

Crucially, alignment expires. Each Timing Alignment Group (TAG) runs a timeAlignmentTimer, restarted whenever a fresh timing command arrives. While the timer runs, the uplink of that group is considered aligned and usable. When it expires, the device must assume it has drifted: it flushes HARQ buffers, releases its PUCCH and SRS resources, and clears configured grants for that group. For the primary group, losing alignment means losing the uplink entirely — the device must perform random access again to re-synchronise before it can transmit.

7 · HARQ — fast retransmission, done right

No radio link is perfect; blocks will sometimes fail to decode. The slow, safe answer is to retransmit at a higher layer, but that costs round-trips and latency. HARQ — Hybrid ARQ — gives MAC a fast, local retransmission loop that not only resends the failed block but combines the failed and resent copies, so that even two individually undecodable transmissions can together carry enough energy to succeed. It is the single biggest reason 5G can run close to the channel's theoretical limit.

HARQ is organised as a set of parallel stop-and-wait processes, one HARQ entity per serving cell. Each process owns one transport block at a time and waits for its outcome before reusing its buffer. Running many processes in parallel — up to sixteen per cell, more with later extensions — hides the round-trip latency of any single one: while process 3 awaits its acknowledgement, processes 4, 5, and 6 keep the pipe full.

New data, or a retransmission?

The device tells new data from a retransmission by the New Data Indicator (NDI), a single bit carried in the scheduling grant. If the NDI has toggled from the last use of that process, the grant carries a fresh transport block, and the device flushes the soft buffer to start clean. If the NDI is held, this is a retransmission of the block already in that process, and the device soft-combines the new energy with what it kept. The Redundancy Version (RV) selects which coded bits are sent; the typical order {0, 2, 3, 1} sends a self-decodable version first, then progressively more parity.

In challenging environments — notably non-terrestrial networks, where the round-trip can be hundreds of milliseconds — per-process HARQ feedback can be disabled entirely, and the network relies on blind repetition and higher-layer ARQ instead. The flexibility to switch HARQ off per process is itself a Release-feature worth knowing.

8 · Multiplexing and the MAC PDU

A transport block is a single opaque chunk to the physical layer, but to MAC it is a carefully structured envelope. The MAC PDU is a chain of sub-PDUs laid end to end, and each sub-PDU is a subheader followed by one of three things: a MAC SDU (data from a logical channel), a MAC control element (MAC's own signalling), or padding to fill the block exactly.

The subheader is what makes the chain reversible on the far side. It carries a Logical Channel ID (the LCID field, six bits, so 64 values) that identifies what follows — which logical channel the SDU belongs to, or which control element this is. For variable-length contents it adds a length field (L, one or two octets) and a format flag (F) saying which. Fixed-size control elements carry no length field at all, because their size is known from their identity. When 64 LCID values are not enough, an escape value selects the extended eLCID space.

Order matters, and it differs by direction. In the downlink, control elements come first, then SDUs, then padding — the network puts its instructions at the front. In the uplink, SDUs come first and most control elements follow, with a few exceptions placed up front for urgency. A handful of special PDUs break the mould: the Random Access Response carries a backoff indicator and per-preamble grant blocks; MsgB serves two-step access; sidelink PDUs carry source and destination identifiers; and transparent transport channels like BCH and PCH carry their payload with no MAC header at all.

9 · Logical-channel prioritisation

When the network grants the device an uplink transport block, the device must decide how to fill it. If only one logical channel has data, the choice is trivial. But a device usually has several flows waiting — a voice stream, a file upload, a signalling message — and a single grant may not fit them all. Logical Channel Prioritisation (LCP) is the algorithm that divides the grant fairly, and it is one of the most elegant pieces of the layer.

The fairness mechanism is a token bucket per logical channel. Each channel is configured with a Prioritised Bit Rate (prioritisedBitRate, the rate the network promises it) and a bucket depth derived from bucketSizeDuration. Tokens — measured in bytes — accumulate into the bucket at the prioritised bit rate, and the bucket is capped so that an idle channel cannot hoard unlimited credit. The running token count for channel j is the variable Bj.

The two rounds

LCP fills the grant in two passes. In the first round, the device serves logical channels in strict order of priority, but each channel is served only up to its current token balance Bj — taking exactly its guaranteed share and no more, and decrementing Bj by what it sent. This protects lower-priority flows from being starved by a greedy high-priority one. If grant space remains after every bucket has had its turn, the second round runs: now priority order alone governs, tokens are ignored, and the highest-priority channel with data takes everything until the grant is full or its data runs out.

10 · Scheduling request and buffer status

The downlink is the network's to schedule freely — it knows what it has to send. The uplink is different: only the device knows it has data, so it must ask. The Scheduling Request and the Buffer Status Report are that conversation, and when uplink latency is high but the radio looks healthy, this is the path to inspect first.

The scheduling request

A Scheduling Request (SR) is the smallest possible message: a single bit on PUCCH that means "I have data and no grant to send it in." It is triggered when a regular buffer status report has been triggered and there is no uplink grant available to carry it. The device transmits the SR on its configured occasions, and a sr-ProhibitTimer enforces a minimum gap so it does not spam the network.

But what if the network never answers? A counter, SR_COUNTER, increments with each SR. When it reaches sr-TransMax, the device gives up on the polite path: it releases its PUCCH and SRS, clears its configured grants, and falls back to random access to force its way onto the air. This escalation — ask, ask, then knock the door down — is exactly the "failing versus waiting" boundary made concrete.

The buffer status report

Where the SR says "I have data," the Buffer Status Report (BSR) says "this much, of this kind." Data is grouped into up to eight Logical Channel Groups (LCGs), and the BSR reports a buffer size per group — not an exact byte count, but an index into a standardised, logarithmically-spaced table, so a few bits can express anything from a handful of bytes to many megabytes.

A regular BSR also arms a retxBSR-Timer: if a grant never arrives to carry the report, the timer re-triggers it so the request is not lost. The format chosen — short, long, or truncated — depends on how many groups have data and how much grant space is available to describe them.

11 · Power headroom — how hard the device is straining

A device has a maximum transmit power, and on every uplink transmission it spends some of it. The Power Headroom Report (PHR) tells the network how much is left over: the difference between the device's configured maximum power and the power its current transmission would require. Positive headroom means the device could be scheduled more aggressively; persistently negative headroom means it is already maxed out and cannot keep up with what it is being asked to send.

That distinction is a coverage diagnostic in disguise. A device failing at the cell edge with negative headroom is power-limited — it physically cannot shout loud enough — which is a fundamentally different problem from interference, and points to a different fix. Reading PHR correctly stops engineers from chasing interference ghosts when the real issue is reach.

There are several report types. Type 1 reports headroom for the PUSCH; Type 3 for the SRS. For carrier aggregation, the Multiple-Entry PHR reports headroom for every activated serving cell at once, each with its own maximum-power octet, so the scheduler can balance power across carriers.

12 · Discontinuous reception — the art of sleeping

A device that monitored the downlink control channel every slot would drain its battery in hours. Discontinuous Reception (DRX) lets it sleep — switch off its receiver — for stretches of time, waking on a schedule to check whether the network has anything for it. DRX is the single biggest lever on device battery life, and its configuration is a direct trade against latency: sleep longer and you save power but answer slower; sleep less and you respond instantly but burn energy.

The rhythm is set by a cycle. The on-duration — the scheduled awake window — begins on the slot where a modulo equation lines up with a configured start offset, repeating every drx-LongCycle. If nothing is scheduled during the on-duration, the device sleeps until the next cycle. But if a grant does arrive, the drx-InactivityTimer starts and keeps the device awake — because activity tends to come in bursts, and it would be wasteful to sleep immediately after the first packet of a flow.

Napping between retransmissions

DRX is clever about HARQ. After a transmission, the device knows a retransmission cannot arrive until at least the round-trip has passed, so the drx-HARQ-RTT-Timer lets it sleep through that dead interval, and the drx-RetransmissionTimer then wakes it precisely when the retransmission could come. Sleep through the wait; wake for the answer.

For bursty-but-quiet traffic patterns, a short cycle can be configured to run first — frequent small wake-ups for a while after activity — falling back to the long cycle once the drx-ShortCycleTimer expires without further data. The device is considered to be in Active Time whenever any of these timers runs, or a scheduling request is pending, or it is mid-contention-resolution; outside Active Time, the receiver is off.

13 · Bandwidth parts — using only the spectrum you need

5G carriers can be enormous — hundreds of megahertz wide. Monitoring and operating across all of that, all the time, would be wasteful for a device that is only trickling data. A Bandwidth Part (BWP) is a contiguous slice of the carrier, and the device operates within one active BWP per direction at a time. Configure a device with up to four, and the network can move it to a narrow BWP when it is idle and a wide one when it needs throughput.

The economy is automatic. A bwp-InactivityTimer runs while the device is on a non-default BWP; when activity stops and the timer expires, the device falls back to its narrower default BWP, saving power. Switching itself is triggered by the scheduling grant (a field in the DCI selects the BWP) or by the timer — and because the active BWP determines which numerology and which control resources apply, BWP operation is tightly woven into both DRX and scheduling.

14 · Carrier aggregation and SCell management

To reach the highest data rates, a device is given more than one carrier — a Primary Cell (PCell) plus one or more Secondary Cells (SCells), their capacities summed. But keeping every SCell fully active when it is not carrying traffic wastes both device and network energy, so MAC manages SCells through explicit activation and deactivation.

The network turns SCells on and off with the SCell Activation/Deactivation MAC control element, a bitmap with one bit per configured SCell. An activated SCell can be scheduled; a deactivated one cannot, and the device need not monitor it. To catch the common case where traffic simply stops, each SCell runs a sCellDeactivationTimer — with no activity before it expires, the SCell deactivates itself automatically, no signalling required.

Between fully on and fully off lies dormancy: a dormant SCell is configured to a dormant bandwidth part where the device does not monitor control but can be woken quickly, giving a fast path back to high throughput without the full cost of reactivation. This three-state model — active, dormant, deactivated — lets the network trade reaction time against power with fine control.

15 · Beam failure detection and recovery

In the millimetre-wave bands, the link is not a soft sphere of coverage but a narrow beam — and a beam can break suddenly when a hand, a wall, or a turning body gets in the way. Beam Failure Recovery is MAC's reflex for catching that break and re-pointing before the connection drops, and it is what keeps high-band 5G usable in the real, moving world.

The device continuously monitors reference signals for beam quality. Each time the measured quality falls below a threshold, a beam-failure instance is counted; a beamFailureDetectionTimer windows the counting so old instances expire. When the count reaches beamFailureInstanceMaxCount, the device declares beam failure — the current beam is no longer trusted.

Recovery then hunts for a replacement. The device looks among candidate beams for one whose quality clears a configured RSRP threshold. For the special cell, it recovers through a contention-free random access on resources tied to the chosen beam — fast and collision-free. For a secondary cell, it sends a Beam Failure Recovery MAC control element naming the failed cell and the new candidate. A beamFailureRecoveryTimer bounds the whole attempt; if it expires without success, the failure escalates to radio-link failure and higher-layer recovery.

16 · The MAC control elements

Scattered through the previous chapters are MAC's own little messages — the timing-advance command, the buffer status report, the SCell activation bitmap. Collectively these are the MAC control elements (CEs), and they are how MAC signals in-band, multiplexed into the very same transport blocks that carry user data, each flagged by a reserved LCID. They are the layer's nervous system: fast, lightweight, and right next to the data they govern.

Because control elements share the transport block with data, they too must be prioritised when space is tight. A defined priority order decides who wins: the most urgent — a C-RNTI or CCCH message, then a configured-grant confirmation, then the buffer status report, then the power headroom report — comes before ordinary data, while a buffer status report generated purely to fill padding sits at the very bottom. When you read a packed uplink PDU, that order is the script it follows.

17 · Sidelink — talking device-to-device

Not all traffic goes through the network. Sidelink lets devices talk directly to one another over the PC5 interface — the basis of vehicle-to-everything safety messaging, public-safety communication, and proximity services. MAC gains a parallel set of channels and procedures for this direct path, mirroring the uplink in spirit but adapted to a peer-to-peer world.

The sidelink shared channel (SL-SCH) carries the traffic, accompanied by Sidelink Control Information (SCI) that tells listeners how and where to decode it. Resources can be allocated two ways. In Mode 1, the gNB schedules the sidelink transmissions, just as it schedules the uplink — appropriate when devices are in coverage. In Mode 2, devices choose their own resources autonomously by sensing the channel: they listen, build a picture of what is already occupied, and select resources likely to be free — essential when out of coverage.

Sidelink even has its own HARQ, acknowledged over the Physical Sidelink Feedback Channel (PSFCH), and its own discontinuous reception (SL-DRX) so that a listening device can save power without missing a peer's transmission. The whole architecture is a study in taking the network-anchored procedures of the uplink and re-deriving them for a setting where there may be no network at all.

18 · What Releases 18 and 19 added

MAC is not a finished layer; each 3GPP release sharpens it for new use cases. Release 18 (5G-Advanced) and Release 19 added procedures that a modern engineer now meets in the field, and while their depth belongs in the dedicated module, their shape is worth carrying.

Small data transmission

Small Data Transmission (SDT) lets a device in the inactive state send a small burst — a sensor reading, a keep-alive — without the full cost of resuming the connection. It comes in two forms: RA-SDT, riding on the random-access exchange, and CG-SDT, riding on a pre-configured grant. For the vast population of infrequent, tiny-payload IoT devices, avoiding a full connection setup every time is an enormous saving.

Faster mobility

L1/L2-triggered mobility (LTM) moves the cell-switch decision down into the lower layers, so a device can change serving cell in response to a fast MAC-level command rather than a slower RRC reconfiguration — cutting handover interruption dramatically. A dedicated LTM cell-switch control element carries the order.

Resting the whole cell

Cell DTX/DRX extends the sleeping idea from the device to the network: a lightly loaded cell can power down its own transmissions and receptions on a schedule, a significant energy-efficiency feature for operators. Alongside these sit support for network-controlled repeaters (NCR) and integrated access and backhaul (IAB), which give MAC control elements for steering relays and repeaters, and continued non-terrestrial network (NTN) enhancements for the long propagation delays of satellite links.

19 · Reading the layer in the field

Everything in this book converges on one practical skill: turning a number on a dashboard into a procedure to inspect. MAC health is network health — trace any accessibility figure, any throughput curve, any latency spike down far enough and you arrive at a MAC procedure. The layer you have just read is your diagnostic index.

Begin every investigation with the master question: is data failing, or is it waiting? Failing means bits are sent but do not get through — that is the radio, HARQ, interference, coverage. Waiting means bits are sitting in a buffer — that is grants, scheduling, requests, timers. Ask that one question and you have already halved the search space before reading a log.

Confirm the suspect in the log, which you can now read as the live control dialogue it is. Name the procedure; find the control element or timer that should be firing; check the timing — was a window missed, did a timer expire before its event; correlate the procedure's behaviour with the KPI; and then tune the configured parameter, because — the golden rule once more — almost every MAC fix is a setting, not a line of code.

Built from 3GPP TS 38.321 / ETSI TS 138 321 v19.1.0 (Release 19), with parameter enumerations defined in TS 38.331. This book narrates the same material as the 21-module 5G NR MAC Masterclass; for field-tuning specifics see the Formula & Parameter Cheat-Sheet and the Theory Deep-Dive reference. · CafeTele · local preview build.