5G NR MAC PDU Format
The MAC PDU is the structured MAC transmission unit that carries MAC SDUs, MAC Control Elements, subheaders, and padding. It is where multiplexing, prioritization, and control signaling become visible in an actual decodable format.
This page explains MAC PDU format as a practical engineering reference. Use it when a trace shows a MAC PDU and you need to understand what was actually carried, why the grant was consumed the way it was, and how to separate data from control. Read it together with 5G NR MAC Overview, Multiplexing and Prioritization, MAC Control Elements, BSR, and PHR when decoding real MAC traces.
| Technology | 5G NR |
|---|---|
| Protocol area | MAC PDU construction and parsing |
| Main specification | 3GPP TS 38.321 |
| Related specifications | 3GPP TS 38.300 and 3GPP TS 38.331 |
| Release baseline | Release 18 |
| Main role | Carry MAC SDUs and MAC Control Elements in a parseable structure |
| Key concepts | Subheaders, LCID, eLCID, MAC SDU, MAC CE, payload order, padding |
| Best paired with | Multiplexing, control elements, BSR, PHR, and trace decoding |
Definition and purpose
A MAC PDU is the protocol data unit exchanged between MAC and PHY over a transport channel. It contains one or more MAC subPDUs, each identified by subheader information that tells the receiver how to parse the following content.
The PDU format matters because it shows what MAC actually transmitted after channel mapping, prioritization, and grant-fit decisions were made. If engineers only know that data existed, but do not inspect the PDU, the real transmitted outcome may still be unclear.
Main building blocks
| Element | Meaning | Why it matters |
|---|---|---|
| MAC PDU | Complete MAC transmission unit | It is the structure actually carried over the selected transport opportunity. |
| Subheader | Parsing information for the following element | Tells the receiver what comes next and how to interpret it. |
| MAC SDU | Upper-layer data delivered into MAC, typically from RLC | Represents user-plane or control-plane payload selected for transmission. |
| MAC Control Element | Compact MAC-layer control information | Carries operational control such as reporting or timing-related information. |
| Padding | Unused filler bits or bytes | Shows that grant size exceeded the useful payload that MAC chose or was able to include. |
MAC PDU layout diagram
The following simplified diagram shows a MAC PDU as a sequence of subheaders and their associated payload parts. Length is not a single fixed value for the whole PDU content. Each subheader and payload block consumes part of the total grant, and the final bytes may be padding.
Subheaders, LCID, and eLCID
Subheaders are the key to PDU parsing. They identify whether the following element is a MAC SDU, a MAC Control Element, or another parse-relevant structure, and they provide the context needed to continue decoding correctly.
LCID and extended LCID interpretation matter because the same PDU can mix control and payload elements. Without correct LCID or eLCID reading, a trace can be parsed incorrectly even when the raw bytes are visible. This is why MAC PDU decoding should always be tied back to the active procedure and surrounding MAC behavior.
How MAC builds the PDU
| Step | What MAC does | Why engineers care |
|---|---|---|
| Select content | Choose MAC SDUs and control elements based on queue state, priority, and procedure context | Explains why some data appears now while other data waits. |
| Add subheaders | Insert parsing metadata ahead of each element | Makes later decoding and interpretation possible. |
| Pack to fit the grant | Arrange selected content within the available transport opportunity | Shows how grant size influenced the final transmitted structure. |
| Add padding if needed | Fill remaining space when the grant is larger than useful selected content | Helps explain unused capacity inside the transport opportunity. |
Practical decode workflow
1. Identify each subheader in sequence
2. Determine whether the next element is an SDU, a control element, or padding
3. Read LCID or eLCID meaning in the current MAC context
4. Separate SDU payload from MAC control information
5. Correlate the final PDU content with grant size, priority, and the active procedureWhat the MAC PDU reveals in real analysis
| Observed PDU pattern | What it can reveal |
|---|---|
| Control elements appear before or alongside data | MAC may be serving immediate procedure control needs as part of the same opportunity. |
| Expected SDU is missing | Priority, grant size, or procedure context may have prevented it from being included. |
| Padding is present | The grant was larger than the final useful selected content. |
| BSR, PHR, or timing-related CE is visible | The real clue may be in compact MAC signaling rather than in higher-layer summaries. |
Common MAC PDU reading mistakes
- Reading payload bytes before understanding the subheaders.
- Assuming the whole grant was used for user data when MAC Control Elements were also present.
- Treating payload order as arbitrary when it often reflects real priority and procedure needs.
- Skipping the procedure context and trying to decode the PDU in isolation.
- Ignoring padding and therefore overestimating how much useful content was really transmitted.
Troubleshooting
| Symptom | PDU area to inspect | Why |
|---|---|---|
| Backlog exists but expected data is missing | Subheaders, LCID interpretation, and packed payload selection | The data may not have been included in that grant at all. |
| Grant exists but throughput gain is weak | Control-element presence and padding versus real SDU payload | Part of the opportunity may have been used for control or not fully used for data. |
| Trace decode looks inconsistent | LCID or eLCID reading and parsing order | A parsing mistake can make the whole PDU interpretation wrong. |
| BSR, PHR, or TA behavior is unclear | MAC Control Elements inside the PDU | The key report or control state may be visible directly in the transmitted structure. |
| Priority behavior is disputed | Actual SDU order and presence inside the PDU | The PDU is where prioritization decisions become observable. |
FAQ
What is a 5G NR MAC PDU?
A MAC PDU is the structured MAC transmission unit that carries MAC SDUs, MAC Control Elements, subheaders, and padding.
Why are subheaders important in MAC PDU decoding?
Because they tell the receiver what the following element represents and how the rest of the PDU should be parsed.
What is the difference between a MAC SDU and a MAC Control Element?
A MAC SDU carries upper-layer payload delivered into MAC, while a MAC Control Element carries compact MAC-layer control information.
Why does padding matter in a MAC PDU?
Padding shows that the grant was larger than the useful selected content, which helps explain how efficiently the transport opportunity was used.
Why should MAC PDU format be studied with multiplexing and prioritization?
Because prioritization decisions become visible only when engineers inspect what MAC actually packed into the PDU.
Why is MAC PDU decoding important for troubleshooting?
Because many real clues, including control elements and omitted payload, only become obvious when the PDU is parsed correctly.