5G NR MAC Control Elements Overview
MAC Control Elements are compact MAC-layer signaling structures carried inside MAC PDUs. They support reporting, timing, control, and feature-specific behavior that must be exchanged efficiently without using full higher-layer messages.
This page explains what MAC CEs are, where they fit, how to read them in traces, and which procedure pages to open next for CE-specific interpretation such as BSR, PHR, Timing Advance, and DRX.
| Technology | 5G NR |
|---|---|
| Protocol area | MAC control signaling |
| Main specification | 3GPP TS 38.321 |
| Related specifications | 3GPP TS 38.300, 3GPP TS 38.331, and feature-specific specs as applicable |
| Release baseline | Release 18 |
| Main role | Carry compact control information inside MAC PDUs |
| Why it matters | Many practical procedure clues and reporting signals appear only as MAC CEs |
| Best paired with | PDU format, BSR, PHR, Timing Advance, DRX, and the CE index |
Definition and purpose
MAC Control Elements are short, structured control entities carried by MAC inside a MAC PDU. They let the UE or gNB exchange operationally important information directly at MAC level without relying on a larger higher-layer message.
They matter because many live procedure signals are exposed through CEs rather than through obvious standalone messages. In trace work, the decisive clue may be a small CE inside a larger MAC PDU rather than the PDU itself.
Where MAC Control Elements fit
- MAC CEs sit inside the MAC PDU alongside MAC SDUs and padding.
- They are identified during PDU parsing through subheader and LCID or eLCID interpretation.
- They support active procedure behavior such as backlog reporting, power reporting, timing control, and feature-state signaling.
- Read them together with the active procedure, not as isolated byte structures.
How MAC Control Elements are carried
| Aspect | MAC CE view | Why it matters |
|---|---|---|
| Container | A MAC CE is carried inside a MAC PDU as a MAC subPDU | The CE is part of the transmitted PDU layout, not a standalone over-the-air message. |
| Identification | The MAC subheader and LCID or eLCID indicate that the following payload is a MAC CE | Correct parsing depends on reading the subheader before reading the payload. |
| Size behavior | Some MAC CEs are fixed-size, while others are variable-size | This changes how the decoder interprets the payload length and structure. |
| Direction | MAC CEs can appear in UL-SCH or DL-SCH context depending on the CE type | Direction is important for correct procedure interpretation and troubleshooting. |
Fixed-size and variable-size MAC CEs
This distinction matters in decodes because fixed-size and variable-size CEs do not parse the same way. Do not assume that every CE has the same length behavior simply because all of them are identified at MAC level.
| Type | Meaning | Typical examples |
|---|---|---|
| Fixed-size MAC CE | The CE payload has a predefined size once the CE type is identified | Timing Advance Command, DRX Command, some activation or indication CEs |
| Variable-size MAC CE | The CE payload length depends on the reporting or control content being carried | BSR, some PHR variants, feature-rich control families |
Main MAC Control Element families
| CE family | Examples | Why it matters |
|---|---|---|
| Reporting CEs | BSR, PHR | Expose uplink demand or power state so the scheduler can react correctly. |
| Timing and alignment CEs | Timing Advance | Support usable uplink timing and continued procedure stability. |
| Activity and efficiency related CEs | DRX-related behavior and adjacent efficiency topics | Help explain monitoring, inactivity, and state-driven traffic visibility. |
| Feature and state control CEs | SCG-related control and newer feature-specific control | Important in advanced configurations where compact control changes behavior significantly. |
MAC CE family map
MAC Control Elements cover much more than basic reporting and timing control. This family also includes activation, beam, sidelink, positioning, IAB, and other advanced feature controls, so it helps to see the wider picture in one place.
Representative MAC CEs
This page highlights representative MAC CE families and points toward the deeper reference pages under this section.
Use this page as the overview. Expand each CE family or CE-specific topic into its own reference page so the full usable content stays on the website.
| Representative CE or CE family | Type | Purpose |
|---|---|---|
| Buffer Status Report MAC CEs | Reporting | Expose backlog state for uplink scheduling decisions. |
| C-RNTI MAC CE | Identity | Carry compact identity-related control in MAC context. |
| UE Contention Resolution Identity MAC CE | Random access related control | Support contention-resolution handling in random access related processing. |
| Timing Advance Command MAC CE | Timing | Control uplink timing alignment. |
| DRX Command and Long DRX Command MAC CEs | Activity | Affect activity and monitoring behavior interpretation. |
| Configured Grant Confirmation MAC CEs | Grant control | Confirm configured-grant related operation and extend MAC control around grant handling. |
| Single Entry and Multiple Entry PHR MAC CEs | Power reporting | Expose uplink power margin in scheduler-facing form. |
| SCell activation or deactivation MAC CEs | Serving cell and feature control | Control serving-cell related activation state in advanced configurations. |
| Duplication activation or deactivation MAC CEs | Duplication control | Control duplication-related behavior in advanced multi-leg transmission contexts. |
| CSI and CSI-RS related MAC CEs | CSI control | Activate, deactivate, or indicate CSI and CSI-RS related reporting and resource behavior. |
| TCI-related MAC CEs | TCI control | Control beam and transmission configuration indication state in advanced downlink and control signaling contexts. |
| SRS-related MAC CEs | SRS control | Activate, deactivate, or indicate SRS-related resources, spatial relations, and pathloss references. |
| PUCCH spatial relation related MAC CEs | PUCCH control | Control PUCCH spatial relation behavior, including enhanced and multiple-TRP cases. |
| Guard symbols and timing delta MAC CEs | Timing and guard control | Carry timing refinement and guard-related control beyond basic timing advance. |
| BFR MAC CEs | Beam failure related control | Support beam failure related control behavior. |
| Sidelink MAC CEs such as sidelink BSR and sidelink DRX command | Sidelink | Extend CE handling into sidelink operation. |
| Inter-UE coordination MAC CEs | Coordination control | Support coordination signaling between UEs in advanced NR operation. |
| Positioning-related MAC CEs | Positioning related control | Support positioning SRS, measurement-gap, and timing-mode related MAC control. |
| Delay Status Report MAC CE | Delay reporting | Expose delay-related status in compact MAC CE form. |
| IAB and NCR related MAC CEs | IAB and NCR control | Support IAB and NCR beam, power, and link-control signaling in advanced deployments. |
Where MAC CEs are used
| Procedure area | Why MAC CEs matter there |
|---|---|
| Uplink scheduling and backlog handling | BSR and related CEs expose demand that affects grant response. |
| Power-limited uplink analysis | PHR helps explain when grants do not translate into expected usable throughput. |
| Uplink alignment and continuity | Timing-related CEs help maintain stable uplink behavior. |
| State or monitoring-sensitive behavior | DRX-related interpretation often depends on compact MAC control and surrounding state. |
| Advanced feature handling | Feature-specific CEs can become the key clue in newer Release 18-oriented scenarios. |
Why MAC Control Elements matter in real analysis
Control elements matter because they carry small but decisive procedure state. A trace can remain ambiguous until the correct CE is identified inside the PDU and read in the right procedural context.
This is especially true for reporting and timing topics. The payload size is small, but the operational meaning is often large enough to change the full troubleshooting conclusion.
Reading notes
- If a trace looks incomplete, the missing clue is often a CE inside the MAC PDU rather than an absent higher-layer message.
- BSR and PHR are among the most operationally valuable CEs because they explain scheduler visibility and uplink feasibility.
- Timing and DRX-related CEs often matter most when behavior looks delayed, sparse, or unstable rather than outright broken.
- Modern NR features add more CE families, so do not reduce “MAC CE” to only classic BSR and Timing Advance examples.
How to read MAC Control Elements in traces
1. Identify the active procedure or troubleshooting symptom
2. Decode the MAC PDU and locate the relevant subheader
3. Determine whether the carried element is a MAC CE
4. Interpret the CE in the current MAC and procedure context
5. Correlate the CE with grant behavior, timing, and neighboring stateCommon MAC CE reading mistakes
- Treating a MAC CE as a standalone message rather than part of a larger MAC PDU and active procedure.
- Ignoring the PDU parsing step and relying only on high-level summaries.
- Reading a CE name correctly but missing its timing context, which can change the conclusion completely.
- Assuming all important procedure state will be visible in RRC or higher layers rather than inside MAC control.
Troubleshooting value
| Symptom | MAC CE area to inspect | Why |
|---|---|---|
| Uplink demand is unclear | BSR | The key clue may be the backlog report inside the PDU rather than a separate summary view. |
| Grant exists but uplink remains weak | PHR and timing-related CEs | The limiting factor may be power or alignment rather than missing opportunity. |
| Uplink continuity looks unstable | Timing Advance | Compact timing control may explain why granted resources were not used effectively. |
| Activity seems absent or delayed | DRX-related interpretation | The clue may be in MAC-visible state and monitoring behavior rather than outright failure. |
| Advanced feature behavior is hard to decode | Feature-specific CEs and the CE index | Newer features often use compact control that is easy to miss without CE-focused reading. |
References
- ETSI TS 138 321 V18.2.0 / 3GPP TS 38.321 Release 18 - main MAC specification covering MAC Control Elements, MAC PDU structure, subheaders, and related MAC procedures.
FAQ
What are MAC Control Elements in 5G NR?
MAC Control Elements are compact MAC-layer structures carried inside a MAC PDU to signal operational control information.
Why are MAC Control Elements important?
Because many real procedure clues, including backlog reporting, power reporting, and timing-related control, appear as MAC CEs rather than as obvious standalone messages.
Where do MAC Control Elements appear?
They appear inside the MAC PDU and are identified during MAC-level decoding and parsing.
Should MAC CEs be studied together with procedure pages?
Yes. The CE format alone is usually not enough. The real engineering meaning comes from reading the CE in the active procedure context.
Is this page the full MAC CE database?
No. This page is the hub. Use the MAC Control Elements Index for lookup-style navigation and use dedicated procedure pages for deeper interpretation.
Are all MAC Control Elements fixed size?
No. Some MAC CEs are fixed-size while others are variable-size, so correct decoding depends on the CE type and the associated subheader interpretation.
Does Release 18 include more than classic BSR and Timing Advance CEs?
Yes. Release 18 MAC CE coverage includes broader power-reporting variants, sidelink-related control, positioning-related control, beam and TCI state related CEs, and other advanced feature control.