MAC PDU, Subheaders & MAC CEs in LTE 4G

Introduction

A MAC PDU in LTE (TS 36.321) is the unit the MAC layer hands down to the physical layer for a single transmission: one transport block, sent once per Transmission Time Interval (the 1 ms subframe) on a shared transport channel such as DL-SCH or UL-SCH. Everything the MAC does — multiplexing several logical channels, inserting in-band control, filling a scheduling grant — ends up as bytes inside this one structure.

It appears on every scheduled transmission in the network. Each time the eNB grants downlink resources or the UE is given an uplink grant, exactly one MAC PDU is assembled to fit the granted transport-block size, packing whatever data and control are waiting. Because the box size is fixed by the scheduler before MAC fills it, the layout has to be self-describing: the receiver must be able to unpack it with no side information.

That is why the MAC PDU format is worth knowing field by field. Its grouped-header layout, its LCID type tags, and its handful of MAC control elements are the vocabulary behind buffer status reporting, timing advance, DRX, contention resolution and carrier-aggregation control — and they are a staple LTE layer-2 interview topic.

Why the MAC PDU is built this way

The reason for the format is multiplexing without extra signalling. A single grant is a scarce, expensive thing, so the MAC packs as much into it as it can: data from several logical channels plus in-band control — a buffer status report, a power headroom report, a timing-advance command — all in one transport block, with no separate signalling round trip. To make that safe, every payload piece is labelled by its own subheader carrying an LCID (what it is) and, when needed, an L field (how long it is). Grouping all those subheaders at the front means an LTE receiver reads the entire packing list first and only then walks the payloads — a byte-aligned layout that is cheap for hardware to parse.

What a MAC PDU is

In LTE (TS 36.321) a MAC PDU is a transport block. It is built by multiplexing several pieces into one byte-aligned bit string: zero or more MAC control elements, zero or more MAC SDUs (each an RLC PDU coming down from a logical channel), and optional padding to fill the transport block exactly. Every one of those payload pieces is described by its own MAC subheader, and — this is the LTE way — all the subheaders are collected together at the start of the PDU.

The transport block size is not chosen by MAC; it is fixed by the scheduler's grant and the modulation and coding scheme signalled in the DCI. MAC's job is to fill that fixed box efficiently: pull the highest-priority control elements first, then as much data as the logical-channel prioritisation rules allow, then pad whatever is left. Because the box size is decided before MAC assembles it, padding is a normal, expected outcome rather than an error — it simply means the grant was larger than the data waiting to be sent.

The layout: headers first, then payloads

Walk a MAC PDU from left to right and you see four zones. First, the block of MAC subheaders. Then the MAC control elements — control comes before data in LTE. Then the MAC SDUs. Finally, if the payloads do not exactly fill the transport block, a single stretch of padding. The n-th subheader describes the n-th payload element, so the ordering of the header block mirrors the ordering of the payload block.

Contrast this with NR (TS 38.321). In NR each MAC subheader sits immediately in front of its own payload — subheader, payload, subheader, payload — so the PDU is a stream of self-contained (subheader + payload) units. NR also puts most control elements at the end of the PDU (before padding) rather than the front, precisely because the interleaved layout lets a device generate the PDU in a single pass without knowing the total size up front. LTE's grouped-header design instead front-loads all the parsing metadata, which is why an LTE receiver reads the whole header block first and only then walks the payloads.

The MAC subheader — R, R, E, LCID, F, L

Each payload element gets exactly one MAC subheader. Its job is to identify the element and, when the element is variable-size, to give its length. LTE defines the subheader fields in a fixed bit order — R, R, E, LCID, then (when present) F and L:

So a subheader takes one of two shapes. A fixed-size element (most CEs, and padding) uses a short subheader — just R/R/E/LCID, one octet. A variable-size element (a data SDU, a long BSR) uses a longer subheader — R/R/E/LCID plus the F/L fields, which add one octet when F=0 (7-bit L) or two octets when F=1 (15-bit L). The E bit is what glues the header block together: each subheader points to the next until one sets E=0, and the byte after that is the first payload.

There is one economy worth knowing: the last element in the PDU never needs an explicit length, because its size is simply "everything remaining in the transport block". So the final subheader before the payloads is a short R/R/E/LCID form even when it describes a variable-size SDU. Likewise, when only a small amount of padding is needed (1–2 bytes), it can be represented by one or two padding subheaders sitting inside the header block itself, rather than a separate padding region at the end — this is why you sometimes see a padding LCID appear among the subheaders.

LCID — one field, three jobs

The LCID is only 5 bits, giving 32 codepoints, and LTE makes a single field do triple duty. A low range identifies real logical channels: 00000 is CCCH, and the values 00001–01010 are the dedicated DCCH/DTCH identities. A block of reserved high values acts as opcodes that each select a particular MAC control element. And one codepoint, 11111, always means padding. Because uplink and downlink carry different control, there are two tables — the DL-SCH LCID table and the UL-SCH LCID table — so the same numeric value can mean different things in each direction.

This is why a receiver never needs external signalling to parse the PDU: the LCID in each subheader tells it unambiguously whether the matching payload is user data for channel N, a specific control command whose format and size it already knows, or padding. Here are the two tables, with the reserved control codepoints spelled out.

MAC control elements — the in-band commands

A MAC control element is a small control message carried inside the MAC PDU rather than as separate RRC signalling — fast, L2-speed, no reconfiguration overhead. Each CE occupies a reserved LCID codepoint and has a fixed, pre-agreed layout, so the receiver knows exactly how to decode it the moment it reads the LCID. Here are the ones you must know, with their reserved LCIDs (binary) and what each achieves:

A few deserve a closer look. The Buffer Status Report family is the heartbeat of uplink scheduling: the UE uses a BSR to tell the eNB how much data is queued. The Short BSR reports a single LCG; the Long BSR reports all four LCGs; and the Truncated BSR is sent when a grant is too small for a Long BSR but more than one LCG has data — it reports the highest-priority LCG and flags that others are non-empty. The Power Headroom Report answers the complementary question — how much power the UE has left to send with — so the eNB avoids grants the UE cannot physically fulfil.

On the downlink, the Activation/Deactivation CE is the fast lever for carrier aggregation: turning an SCell on via a MAC CE takes a few milliseconds versus the tens of milliseconds an RRC reconfiguration would cost, which is exactly why LTE-A moved SCell control down to the MAC layer.

The RAR — a special MAC PDU

The Random Access Response (Msg2) is delivered as a MAC PDU too, but a special one with its own subheader types and its own control element. It follows the same shape — a header block of subheaders at the front, then payloads — but the payloads are MAC RARs instead of SDUs, and there are no MAC SDUs or normal MAC CEs at all. A single RAR PDU can answer several UEs at once, one MAC RAR per detected preamble.

The RAR MAC header uses two subheader types, distinguished by a T (type) bit that replaces the usual LCID:

Each RAPID subheader corresponds to one MAC RAR payload, a fixed 6-octet (48-bit) structure: 1 reserved bit, an 11-bit Timing Advance Command (the initial uplink timing correction), a 20-bit UL Grant for the Msg3 transmission, and a 16-bit Temporary C-RNTI. The 20-bit grant is itself packed: a hopping flag (1 bit), a fixed-size resource-block assignment (10 bits), a truncated modulation-and-coding-scheme field (4 bits), a TPC command for PUSCH (3 bits), a UL delay bit (1 bit), and a CSI-request bit (1 bit) — everything the UE needs to send Msg3 without any further downlink control.

How MAC builds and orders the PDU

Assembling a MAC PDU is a priority exercise bounded by the transport block size. On the uplink the UE runs logical channel prioritisation: control elements are placed first (a C-RNTI or a UE contention resolution takes precedence, then BSR/PHR), after which each logical channel is served in strict priority order up to its prioritised bit rate, then round-robin for whatever grant remains. Anything the grant cannot fill becomes padding. On the downlink the eNB does the equivalent, deciding which SDUs and control elements to multiplex into each UE's transport block.

The ordering rules are worth stating precisely, because they are fixed and a receiver relies on them:

Put together, these rules make the PDU self-describing. A receiver reads R/R/E/LCID repeatedly, collecting length information from F/L where present, until it hits E=0. It now knows the count, type and size of every payload element, and can slice the remainder of the transport block into control elements, SDUs and padding without any side information — which is the whole point of grouping the headers at the front.

Summary

An LTE MAC PDU is one transport block, sized by the scheduler's grant, that the MAC fills by multiplexing. Its defining trait is layout: all MAC subheaders are grouped as a contiguous block at the front, in payload order, followed by the MAC control elements, then the MAC SDUs, then a single optional padding region. Control comes before data, and the whole thing is octet-aligned so a receiver can parse it with no side information.

Each subheader is R/R/E/LCID, extended with F/L when its payload is variable-size. The E bit chains the header block; the LCID does triple duty — a low value names a logical channel, a reserved high value selects a specific control element, and 11111 means padding — with separate DL-SCH and UL-SCH tables so the same value (e.g. 11011 = C-RNTI uplink vs. SCell Activation/Deactivation downlink) can differ by direction. The last element needs no L because its size is "the rest of the TB".

The MAC control elements — Buffer Status Report, Power Headroom Report, C-RNTI, UE Contention Resolution Identity, Timing Advance Command, DRX Command, SCell Activation/Deactivation — are in-band commands that operate at L2 speed, avoiding an RRC round trip. The RAR (Msg2) is a special MAC PDU whose header uses BI and RAPID subheaders (a T bit instead of an LCID) and whose payloads are fixed 6-octet MAC RARs carrying the initial TA, a 20-bit UL grant and a Temporary C-RNTI. Parse the header block first and every LTE MAC PDU becomes self-describing.

Quick Q&A