BSR (Buffer Status Reporting) in LTE

In LTE uplink, the eNodeB controls when a UE may transmit on PUSCH by sending uplink grants (via DCI). But the eNB can only schedule intelligently if it knows:

• Which UE has data to send
• How much data is waiting
• How urgent that data is (priority / QoS behavior)

That “UL backlog visibility” is exactly what Buffer Status Reporting (BSR) provides.
3GPP defines BSR as a MAC-layer procedure used “to provide the serving eNB with information about the amount of data available for transmission in the UL buffers associated with the MAC entity.”
In Simple These logical channel groups currently have X bytes pending (after I built this TTI’s MAC PDUs).

This is a foundational building block for:

• UL scheduling fairness and efficiency
• Meeting latency needs (VoLTE, URLLC-like low latency services in LTE evolution)
• Avoiding UL starvation, jitter, and unnecessary scheduling requests

Where BSR sits in the LTE UL scheduling loop

In LTE uplink, the eNB can’t just let the UE transmit anytime, it must schedule the UE by giving it an UL grant. To schedule properly, the eNB needs to know how much data the UE has waiting. That’s why the UE uses BSR: it’s a small MAC-layer control message that tells the eNB the UE’s pending uplink buffer size (grouped by LCG). If the UE doesn’t yet have uplink resources to send BSR, it can first send an SR Scheduling Request to ask for a grant.

Steps involved

• App generates data-Some application (upload, voice, messaging, etc.) creates uplink data.
• PDCP → RLC buffers build up-Data enters the LTE stack and starts queuing in PDCP/RLC buffers.
• MAC sees bytes pending (per LCG)-MAC checks how many bytes are waiting, organized by Logical Channel Groups (LCG).

• UE triggers BSR (or SR)
  • If there’s pending data, UE prepares a BSR to report buffer status.
  • If UE has no UL grant yet, it may send SR first to request uplink resources.

• eNB receives info and schedules UL grant-eNB uses BSR/SR to decide when and how many resources to allocate to the UE.
• UE transmits on UL-SCH
  • UE sends actual uplink data on UL-SCH.
  • The BSR (can be included along with the data.

What exactly is “buffer status” in LTE?

In LTE uplink, the term buffer status has a very specific and precise meaning. It does not simply indicate that the UE has data to send; rather, it quantifies how much uplink user data is waiting inside the UE at the time the Buffer Status Report is generated. This information allows the eNB to make accurate and efficient uplink scheduling decisions.

From a standards perspective, buffer status is always viewed from the MAC layer, but the data itself originates from upper layers. Understanding which data is counted and when it is measured is critical for correct interpretation of logs, traces, and scheduler behavior.
For BSR, the Buffer Size field represents the total amount of data available for transmission across all logical channels belonging to a Logical Channel Group (LCG). Importantly, this data is not limited to a single protocol layer.

The buffer size must include data available in:

• PDCP layer
• RLC layer

In other words, any uplink data that has already entered the LTE protocol stack and is waiting in PDCP or RLC buffers is considered part of the buffer status.

The LTE specifications are very explicit on this point. The definition of what data is considered “available for transmission” is governed by:

• RLC specification (TS 36.322)
• PDCP specification (TS 36.323)

A crucial clarification given by the standard is that:

• RLC header sizes are not included
• MAC header sizes are not included

Only the actual user payload bytes waiting to be transmitted are counted.
This detail is extremely important during troubleshooting and performance analysis. Engineers often expect the buffer size reported in BSR to match the number of bytes sent over the air, but that is not correct.
All BSRs transmitted in a TTI always reflect the buffer status after all MAC PDUs have been built for this TTI.”
This means the buffer size is not a snapshot taken before transmission, but rather after the UE has already decided what to transmit in the current TTI.

RRC configuration that drives BSR behaviour

In LTE, the RRC layer plays a key role in controlling how and when the UE reports its buffer status. Although the BSR is a MAC-layer procedure, its behavior is largely governed by parameters configured by RRC, as specified in 3GPP TS 36.321.
RRC controls BSR reporting through the following key configurations:

• PeriodicBSR-Timer-Defines how often the UE sends a periodic update of its uplink buffer status, even if no new data arrival occurs.
• retxBSR-Timer-Ensures that the UE re-reports its buffer status if uplink data is still pending and no effective scheduling has occurred.
• logicalChannelSR-ProhibitTimer-Controls whether a Scheduling Request (SR) can be triggered when a Regular BSR occurs, preventing excessive SR transmissions.
• Logical Channel Group (LCG) mapping-Each logical channel can be assigned to an LCG (0–3), allowing the UE to report buffer status in grouped form rather than per bearer.

The actual LCG mapping is configured by RRC within LogicalChannelConfig (defined in TS 36.331), where the parameter logicalChannelGroup (0..3) appears under UL-specific configuration. This mapping directly determines how uplink buffers are grouped and reported in BSRs.

BSR Trigger Types in LTE

In LTE, the Buffer Status Report is not sent randomly. As defined in 3GPP TS 36.321, the UE triggers a BSR only under specific conditions so that the eNB receives timely and meaningful uplink buffer information without unnecessary overhead. There are four main BSR trigger types, each serving a distinct purpose in uplink scheduling.

Regular BSR (Data Arrival / Priority-Based)
A Regular BSR is triggered when new uplink data becomes available for transmission in a logical channel belonging to an LCG, and one of the following conditions is met:

• The new data belongs to a higher-priority logical channel than those already having pending data in other LCGs, or
• There was no data previously available for any logical channel in that LCG.

This ensures that the eNB is immediately informed when a new or more urgent uplink backlog appears.

Periodic BSR
A Periodic BSR is triggered when the periodicBSR-Timer expires.
Its role is simple but important: it keeps the eNB periodically updated about the UE’s uplink buffer status, even when no new data arrival or priority change has occurred.

Regular BSR due to retxBSR-Timer Expiry
If the retxBSR-Timer expires and the UE still has pending uplink data in any LCG, a Regular BSR is triggered again.
This mechanism allows the UE to re-announce its buffer status in case a previous BSR was not successfully delivered or acted upon by the scheduler.

Padding BSR
A Padding BSR is triggered opportunistically when:

• The UE already has uplink resources allocated, and
• There are enough padding bits in the MAC PDU to carry a BSR MAC Control Element (plus subheader).

This allows the UE to inform the eNB about its buffer status at almost no extra cost, using otherwise unused bits.

BSR Formats: Short, Long, and Truncated

LTE supports multiple BSR formats to efficiently report buffer status depending on how many Logical Channel Groups are active and how much space is available in the MAC PDU.
MAC CE Structure

According to TS 36.321:
Short BSR / Truncated BSR

• LCG ID: 2 bits
• Buffer Size: 6 bits

Long BSR
Four Buffer Size fields, one for each LCG (LCG 0–3), each 6 bits
Payload size comparison:

• Short / Truncated BSR: 8 bits (1 octet)
• Long BSR: 24 bits (3 octets)

When Short vs Long BSR is Used
For Regular and Periodic BSR:

• If more than one LCG has data to report in the transmission TTI → Long BSR
• If only one LCG has data → Short BSR

When Truncated BSR is Used (Padding Case)
For Padding BSR:

• If padding is sufficient for a Short BSR but not for a Long BSR:
  
  • If multiple LCGs have data → send a Truncated BSR for the LCG containing the highest-priority logical channel
  • Otherwise → send a Short BSR
    
• If padding is sufficient for a Long BSR → send a Long BSR

This approach ensures that at least partial buffer information is conveyed even when space is limited.
 
Below table shows how uplink buffer size is encoded in a BSR in LTE.

• Instead of reporting the exact number of bytes, the UE sends a 6-bit index (0–63), where each index represents a range of buffer sizes in bytes.
• The MAC layer selects the index whose range contains the actual pending payload data (from PDCP and RLC).
• This approach reduces signaling overhead while still giving the eNB a good estimate of how much uplink data is waiting.
• For very large buffers, the highest index (63) simply indicates “more than 150 KB pending”, without reporting the exact value.

Extended BSR Sizes

In LTE, extended BSR sizes are used when the standard buffer size range is not sufficient. As specified in 3GPP TS 36.321, if extendedBSR-Sizes is configured, the UE uses an alternative buffer size mapping table (Table 6.1.3.1-2) instead of the normal one.

This capability is signalled by RRC through the parameter extendedBSR-Sizes-r10 within the MAC main configuration extensions. Extended BSR sizes are typically relevant in high uplink throughput scenarios, very large UL buffers (such as uplink-heavy TCP transfers), and in certain carrier aggregation or feature-rich configurations where reporting a wider buffer range improves scheduling efficiency.

Example to explain the BSR

Consider a UE uploading a large file (for example, a cloud backup) over LTE.

• Data enters the uplink stack-The application generates uplink data, which is buffered in the PDCP and RLC layers. Assume that after buffering, the UE has 12 KB of data waiting to be transmitted.
• MAC evaluates buffer status per LCG-All the logical channels carrying this upload belong to LCG-1. The MAC calculates the total pending payload data for LCG-1 as 12,000 bytes (headers not included).
• UE triggers a BSR-Since new uplink data has become available, the UE triggers a Regular BSR.
• Using the BSR buffer size table, 12,000 bytes maps to Index 46 (10,287 < BS ≤ 12,043 bytes).
• BSR is sent to the eNB
• The UE includes a Short BSR in its uplink transmission, indicating:
  • LCG ID = 1
  • Buffer Size Index = 46
• eNB schedules uplink resources-After receiving the BSR, the eNB understands that the UE still has a large amount of uplink data pending and allocates a larger UL grant in the next scheduling interval.

The UE does not send “12 KB” directly to the eNB. Instead, it sends a compact BSR index that represents this buffer range, allowing the eNB to efficiently decide how much uplink resource to assign next. This is the core purpose of BSR in LTE.
 

References

• 3GPP TS 36.321 – E-UTRA MAC protocol specification (BSR procedure, triggers, formats, buffer size tables)
• ETSI TS 136 321 – ETSI version of LTE MAC specification (Release 16 and earlier)
• 3GPP TS 36.331 – E-UTRA RRC protocol specification (LCG mapping, MAC-MainConfig, BSR timers, extended BSR sizes)
• 3GPP TS 36.322 – RLC protocol specification (uplink buffering and data availability definition)
• 3GPP TS 36.323 – PDCP protocol specification (PDCP buffering contributing to BSR)
• 3GPP Official Specifications Portal – https://www.3gpp.org