5G NR MAC Buffer Status Report (BSR)
Buffer Status Report is the MAC mechanism used by the UE to indicate uplink backlog to the scheduler. It is one of the most important MAC signals for understanding whether the network had the right visibility into real uplink demand.
This page explains BSR from a scheduler and troubleshooting perspective. In live networks, BSR is often the difference between guessing that the UE has data and knowing how the network sees the uplink queue state. Use it together with Scheduling Request, Power Headroom Report, and the 5G NR MAC Overview page when analyzing uplink performance end to end.
| Technology | 5G NR |
|---|---|
| Protocol area | MAC uplink reporting |
| Main specification | 3GPP TS 38.321 |
| Related specifications | 3GPP TS 38.331 and 3GPP TS 38.214 |
| Release baseline | Release 18 |
| Main role | Expose uplink backlog to the scheduler |
| Key variants | Short, long, and truncated BSR |
| Best paired with | Scheduling Request, multiplexing, MAC PDU decoding, grants, and troubleshooting |
Definition and purpose
BSR is the MAC-level report that tells the network how much uplink data is waiting. It helps the scheduler make resource decisions based on reported backlog rather than guesswork.
When BSR is stale, absent, delayed, or misread, the network may under-serve or misinterpret real uplink demand. That is why BSR is one of the most valuable MAC signals for uplink troubleshooting.
BSR variants
| BSR type | Purpose | Why it matters in analysis |
|---|---|---|
| Short BSR | Compact report for limited backlog visibility | Useful when only a smaller amount of queue context is carried. |
| Long BSR | Broader report across logical channel groups | Useful when fuller backlog visibility is needed for scheduler interpretation. |
| Truncated BSR | Constrained reporting form | Important because it can indicate restricted reporting conditions or partial visibility. |
Where it fits
- BSR is part of the MAC uplink demand-signaling chain.
- Scheduling Request can indicate that uplink opportunity is needed.
- BSR adds backlog detail so the scheduler can estimate how much data is waiting.
- Later grant behavior shows whether the network responded in a way that matched the reported demand.
Trigger conditions
| Trigger area | Why BSR becomes relevant |
|---|---|
| Buffered uplink data exists | The UE has backlog that should be made visible to the scheduler. |
| Scheduling state requires queue visibility | The network needs backlog context to decide grant size and timing. |
| Reporting opportunity exists | The MAC procedure has an opportunity to carry the report. |
| Procedure context changes | The usefulness of a BSR depends on when it is generated relative to grants and queue buildup. |
Logical channel group context
BSR becomes much more useful when it is read in the context of logical channel grouping. Different service groups may have different demand at the same time, and the scheduler reacts based on what it can see through those groups.
This is why a statement like “the UE has backlog” is often not enough. The useful question is which logical channel group has backlog, how much is visible, and whether that matched the later grant behavior and priority outcome.
How to correlate BSR with grants
| Observation | What it can mean |
|---|---|
| BSR rises and grants also rise | The scheduler is seeing demand and responding to it. |
| BSR rises but grants stay weak | Demand visibility exists, but grant response is still limited. |
| BSR appears stale while traffic is waiting | Reporting visibility, state timing, or decoding may be hiding the true queue picture. |
Scheduler relevance
- BSR helps the scheduler judge the scale of uplink demand.
- BSR must be read together with grant timing and size, not in isolation.
- BSR is especially valuable when verifying whether the network had the right visibility into queued traffic.
- BSR interpretation becomes stronger when logical channel group context is understood alongside SR and later grant behavior.
Typical BSR-related problem patterns
- Backlog exists but reports do not appear when expected.
- Reports appear but grant response is consistently smaller than the visible demand.
- Reports are visible but queue drain is still poor because priority, power, or HARQ constraints dominate.
- Trace decodes show a BSR, but the interpretation is incomplete because logical channel group context was skipped.
Log-analysis notes
A useful BSR analysis should correlate actual buffered data, the visible BSR form, the logical channel group context, and the later grant response. Without that correlation, a decoded BSR can be technically correct but operationally misleading.
BSR is especially valuable when paired with Scheduling Request, MAC PDU decoding, Power Headroom Report, and HARQ if queue drain remains poor after grants arrive.
Troubleshooting
| Symptom | BSR area to inspect | Why |
|---|---|---|
| Backlog exists but no report appears | BSR trigger and reporting opportunity | The scheduler may not have gained correct queue visibility. |
| BSR appears but grants remain weak | Grant response relative to reported backlog | Demand visibility exists, but scheduler response may still be constrained. |
| Reported backlog looks inconsistent | Logical channel group interpretation and MAC PDU decoding | The BSR may be real but decoded or interpreted incorrectly. |
| Queue drain stays poor after grants | BSR together with PHR, HARQ, and prioritization | The limiting factor may no longer be backlog visibility itself. |
| Intermittent uplink behavior | Procedure timing, DRX state, and stale reporting view | BSR timing can be correct in one context and misleading in another. |
What to check when BSR looks wrong
- Check whether buffered traffic existed at the time you expected the report.
- Check whether DRX, scheduling state, or procedure timing changed report visibility.
- Check whether the scheduler reacted with grants that matched the reported demand.
- Check MAC PDU parsing so the BSR itself is being interpreted correctly.
FAQ
What is BSR in 5G NR MAC?
BSR is the Buffer Status Report used by the UE to indicate uplink backlog to the scheduler.
Why is BSR important?
Because it gives the network visibility into queued traffic so grant decisions can match real demand.
How is BSR different from Scheduling Request?
Scheduling Request indicates that uplink opportunity is needed, while BSR gives stronger backlog detail about queued data.
What are the main BSR forms?
The main forms commonly referenced are short BSR, long BSR, and truncated BSR.
Why can BSR and throughput disagree?
Because backlog visibility alone does not guarantee timely or large enough grants, and radio conditions, power limitation, prioritization, or retransmissions may still limit usable throughput.
Why does logical channel group context matter in BSR analysis?
Because scheduler interpretation depends on where the visible backlog exists, not just on the fact that some uplink queue is present.