5G NR MAC PDU Structure

1.Introduction

In 5G baseband / protocol validation, understanding MAC PDU decoding is critical — especially when debugging uplink scheduling issues, BSR anomalies, TA problems, or HARQ behavior in logs.

This article provides:

• NR MAC PDU structure (DL & UL)

• Subheader parsing logic

• LCID types and mapping

• MAC SDU vs MAC CE types

• UE log decoding walkthrough

• Comparison with LTE MAC PDU

• Real-time debugging perspective

MAC Layer in 5G NR

The MAC layer sits between:

• RLC (above)

• PHY (below)

Responsibilities:

• Multiplexing logical channels

• Scheduling

• HARQ

• BSR handling

• Timing Advance

• DRX

• Power headroom reporting

Unlike LTE, NR MAC was redesigned for:

• Flexible numerology

• Massive MIMO

• Dynamic TDD

• Beam management

Below is the End-to-End Flow for both Downlink and Uplink messages from gNB and UE perspective.

End-to-End Flow (DL Example)

Step 1 — Scheduler builds the Transport Block (TB) The gNB's MAC scheduler decides what to send and how to send it. It picks the Modulation and Coding Scheme (MCS) based on the UE's channel quality (CQI feedback), allocates Physical Resource Blocks (PRBs) in the frequency domain, and calculates the transport block size — essentially the "envelope" that will carry the data.

Step 2 — MAC multiplexes SDUs + Control Elements (CEs) The MAC layer fills that envelope. It takes RLC SDUs (actual user data chunks from the layers above) and bundles them alongside Control Elements — small commands like Buffer Status Reports (BSR), Timing Advance (TA), or DRX instructions. Each piece gets a subheader stamped on it (containing LCID and length), so the receiver knows exactly what's inside and where each piece starts and ends.

Step 3 — PHY encodes the TB The Physical layer takes the assembled MAC PDU and makes it radio-ready. It applies LDPC forward error correction coding, rate-matches the bits to fit the allocated PRBs, modulates the bits (QPSK / 16QAM / 64QAM / 256QAM), and maps everything onto the PDSCH (Physical Downlink Shared Channel) resource grid for transmission.

The signal travels over the air. It faces real-world impairments — multipath fading, interference, noise. This is why HARQ and LDPC exist: to recover data even when the channel is imperfect.

Step 4 — UE decodes the TB The UE's PHY layer receives the PDSCH signal, performs HARQ soft combining (if it has stored previous failed attempts), and runs LDPC decoding to recover the original bits. It then sends an ACK (success) or NACK (failure, request retransmit) back to the gNB on the PUCCH channel.

Step 5 — UE parses subheaders Now the UE's MAC layer looks at the subheaders that were stamped in Step 2. It reads the LCID (Logical Channel ID) and length field for each entry, building a map of exactly where in the PDU each SDU or CE lives. Think of it like reading the table of contents before opening chapters of a book.

Step 6 — CE processed first This ordering is mandated by the 3GPP spec. Control Elements carry time-sensitive signaling — timing corrections, power headroom, scheduling feedback — that must be acted on before data is handed upward. If TA is applied after data is processed, the timing would be wrong for the next uplink transmission.

Step 7 — SDU forwarded to RLC Finally, with CEs handled, MAC strips its headers and delivers each SDU payload upward to the RLC (Radio Link Control) layer. RLC then handles reassembly of segmented PDUs, duplicate detection, and in-order delivery before passing data further up to PDCP and eventually the application.

End-to-End Flow (UL Example)

In the uplink direction, the UE's RLC layer submits RLC PDUs to the MAC layer via logical channels. Depending on the RLC mode configured for the bearer, these take slightly different forms:

RLC AM (Acknowledged Mode) — used for most data bearers Submits AMD PDUs, which contain a sequence number, polling bit, segmentation/reassembly flags, and the RLC SDU (or a segment of one). If earlier transmissions failed HARQ, RLC AM also submits retransmission PDUs for those sequence numbers.

RLC UM (Unacknowledged Mode) — used for VoIP, streaming Submits UMD PDUs with a sequence number and segmentation indicators, but no retransmission logic. Lost PDUs are simply dropped.

RLC TM (Transparent Mode) — used for CCCH (SRB0) Passes the SDU through with no RLC header at all. Used for initial access messages like RRCConnectionRequest.

What MAC does with them MAC treats each RLC PDU as an SDU from its perspective. When the scheduler grants uplink resources (via UL grant on PDCCH), the UE MAC:

1. Requests SDUs from RLC for each active logical channel, up to the granted TB size

2. Segments or pads as needed to fill the TB exactly

3. Builds subheaders (E, LCID, F, L) for each SDU

4. May prepend MAC CEs like BSR or PHR before the SDUs

5. Hands the completed MAC PDU down to PHY for encoding and PUSCH transmission

2. 5G NR MAC PDU Structure

A MAC PDU is the complete packet created by the MAC layer and transmitted to the PHY layer.

The MAC PDU is used to:

• Carry user data from upper layers• Carry control information required for radio operation• Fit the payload into the Transport Block Size (TBS) scheduled by the gNB

It contains:

• MAC subheaders

• MAC SDUs

• MAC Control Elements (CEs)

• Padding (if needed)

MAC Subheader fields (one per payload unit):

• R (Reserved) — 1-bit reserved field, always set to zero, ensures byte alignment.

• F (Format) — 1-bit flag; 0 = 8-bit length field, 1 = 16-bit length field for large SDUs.

• LCID — 6-bit Logical Channel ID; identifies which bearer (DRB/SRB) or CE type this entry carries. 

• L (Length) — 8 or 16-bit field giving the byte count of the following SDU or CE.

• E-LCID (Extended LCID) — optional 8-bit extension for CEs introduced after Rel-15 when 6-bit LCID space is exhausted.

MAC SDU — the actual RLC/PDCP payload; variable length, mapped 1-to-1 with the preceding subheader's LCID and L value.

MAC Control Elements:

• BSR (Buffer Status Report) — reports per-LCG uplink queue sizes so the gNB can schedule UE transmissions efficiently.

• PHR (Power Headroom Report) — reports the UE's remaining transmit power margin, enabling gNB power control decisions.

• C-RNTI CE — carries the UE's Cell-RNTI during contention resolution in random access procedures.

• TA Command — gNB-originated timing advance correction value to keep UL symbols time-aligned at the base station.

Padding — zero-filled bytes appended last to match the exact transport block size granted by the scheduler; identified by LCID = 63 (0b111111) with no length field.

Key rule:

Subheaders appear first, then payloads in the same order.

Fixed vs Variable Length CE in NR

CE Type	Length Type
TA	Fixed
DRX Command	Fixed
Short BSR	Fixed
Long BSR	Variable
CRI	Fixed

Fixed-length CEs:

• No L field

• Known size from spec

3. How MAC PDU Decoding Works (Step-by-Step)

DL-SCH Bit-Level Decoding Example

Example Hex Stream

21 14 3D 00 7F

We decode step-by-step.

Step 1: First Byte = 0x21

0x21 = 0010 0001 (binary)

Split:

R = 0F = 0LCID = 000001 (decimal 1)

✔ LCID = 1 → DCCH (DL logical channel)

Step 2: Length Field

F = 0 → next byte is 8-bit length

Next byte = 0x14 = 20 bytes

✔ So:

Next 20 bytes → MAC SDU (RRC message)

Step 3: Next Subheader = 0x3D

0x3D = 0011 1101

R = 0F = 0LCID = 111101 (decimal 61)

✔ LCID = 61 → Timing Advance CE (DL)

·       Fixed length → 1 byte

·       No length field

Step 4: Read TA Value

Next byte = 0x00 → TA command value

Step 5: Next Subheader = 0x7F

0x7F = 0111 1111

R = 0F = 1 (ignored for padding)LCID = 111111 (63)

✔ LCID = 63 → Padding

Stop parsing

Final DL Decoded Output

Byte	Meaning
0x21	DCCH subheader
0x14	Length = 20
Next 20 bytes	MAC SDU
0x3D	TA subheader
0x00	TA value
0x7F	Padding

UL-SCH Bit-Level Decoding Example

Example Hex Stream

3D 05 AA BB CC DD EE 3F

Step 1: First Byte = 0x3D

0x3D = 0011 1101

R = 0F = 0LCID = 111101 (decimal 61)

✔ LCID = 61 → Short BSR (UL)

• Fixed length = 1 byte

• No length field

Step 2: Read BSR Value

Next byte = 0x05

Interpretation:

• Encodes buffer size index

Step 3: Next Subheader = 0xAA

0xAA = 1010 1010

R = 1 (ignored)F = 0LCID = 101010 (decimal 42)

⚠ LCID 42:

• Must be checked against UL LCID table

• If not valid → decoding error OR vendor-specific/log issue

UL Example

04 05 AA BB CC DD EE 3F

Decode 0x04

0x04 = 0000 0100

R = 0F = 0LCID = 000100 (4)

✔ LCID = 4 → DTCH

Step 4: Length

Next byte = 0x05 → 5 bytes

Step 5: Read SDU

AA BB CC DD EE → 5 bytes user data

Step 6: Next Subheader = 0x3F

0x3F = 0011 1111

LCID = 63 → Padding

Final UL Decoded Output

Byte	Meaning
0x3D	Short BSR
0x05	BSR value
0x04	DTCH subheader
0x05	Length
Data	MAC SDU
0x3F	Padding

4.  LTE MAC PDU Structure

Now let’s compare with LTE.

LTE MAC PDU Format

The LTE MAC subheader sits in front of every MAC SDU or MAC CE in a MAC PDU, telling the receiver what follows and how long it is. It contains four fields:

E — Extension bit (1 bit) Indicates whether more subheaders follow. Set to 1 if there is at least one more subheader after this one; set to 0 on the last subheader in the PDU. This is how the receiver chains through all the subheaders before reading the payload.

LCID — Logical Channel ID (5 bits) Identifies what the following payload actually is. For data, it specifies which radio bearer (logical channel) the SDU belongs to. For control, specific reserved LCID values identify MAC CEs — for example, BSR, Timing Advance Command, Power Headroom Report, and so on. The receiver uses this to route the payload to the right entity.

F — Format flag (1 bit) Controls the width of the L field that follows. When F = 0, L is 7 bits wide (enough for SDUs up to 127 bytes). When F = 1, L is 15 bits wide (up to 32767 bytes). The scheduler sets this based on how large the SDU actually is, keeping short SDUs compact.

L — Length field (7 or 15 bits) Specifies the size of the associated MAC SDU or CE in bytes. The receiver reads this to know exactly how many bytes to consume for that payload before moving to the next subheader. MAC CEs with a fixed, well-known size sometimes omit the L field entirely since its value would be redundant.

LTE vs NR MAC PDU Comparison

Feature	LTE	NR
Extension Bit	Yes (E bit)	No
Flexible design	Limited	Highly flexible
Length field	Conditional	F-based
Beam mgmt support	No	Yes
Multiple numerology	No	Yes
UL BSR design	Fixed types	Enhanced types

Key Structural Difference

LTE uses "E bit"

Each subheader indicates if another subheader follows.

NR does NOT use E bit

Instead:

• Parsing continues sequentially

• Based on remaining TBS

This simplifies parsing logic.

Decoding Algorithm (NR)

Pseudo-decoding logic:

while (bytes_remaining > 0):   

read first byte    extract R, F, LCID       

if fixed_length_CE:       

read CE payload   

else:       

read length field (8 or 16 bit)       

read payload of length L       

if LCID == padding:       

stop

In baseband debugging, this is critical when:

• MAC decoding mismatch occurs

• RLC not receiving expected PDU

• BSR missing in UL grant

Debug Problem:

UE not getting uplink grant increase.

Check UL MAC log:

LCID: DTCH(no BSR present)

Root Cause:UE not inserting BSR CE.

Possible reasons:

• No BSR triggered

• Retx BSR pending

• Scheduler misinterpretation

Without MAC PDU decode knowledge, this issue is invisible.

5. Summary

The 5G NR MAC PDU is the final packet transmitted over the air interface, constructed by multiplexing:

• MAC SDUs → actual payload from upper layers (RLC: RRC signaling or user data)

• MAC Control Elements (MAC CEs) → MAC-generated control information (e.g., BSR, TA, DRX)

• Subheaders → metadata indicating LCID, length, and payload type

• Padding → fills remaining transport block size

6.      References

1.      3GPP TS 38.321, MAC PDU structure ,LCID tables (DL-SCH & UL-SCH) and

MAC CE definitions

2.      3GPP TS 38.300, Layered architecture overview , MAC layer role in NR

3.      3GPP TS 38.213, Scheduling, HARQ, timing alignment

4.      3GPP TS 38.214, Transport block size (TBS) , DL/UL data transmission behaviour

5.      https://www.sharetechnote.com/html/5G/5G_MAC.html