BSR, PHR & Scheduling Request in LTE 4G

Introduction

Uplink in LTE is scheduled by the eNB, but all the information the scheduler needs lives inside the UE. Downlink is easy — the eNB owns its own buffers and its own power amplifier. Uplink is opaque: only the UE knows when data arrived, how much is queued on each bearer, and how much transmit-power margin remains at the current path loss. SR, BSR and PHR are the three MAC-layer reports that make the invisible visible so the scheduler can act on fact instead of guesswork.

They run constantly during an active connection. Every time a UE with no grant gets new data, an SR fires; every time the buffer picture changes or a periodic timer expires, a BSR fires; every time path loss shifts or a timer expires, a PHR fires. Between them they open, size and power-check every uplink transmission that is not on a pre-configured grant.

Because the three reports chain into one another — SR wins a foothold, BSR quantifies the need, PHR rides on the data that follows — a stall almost always lives in one specific handoff. Knowing which report failed (no grant after SR? wrong grant size after BSR? power-limited allocation?) narrows the root cause enormously, which is exactly why a step-by-step reading of the trio pays off.

Why the Uplink Reporting Trio Exists

Uplink scheduling in LTE is a chicken-and-egg problem. To send data the UE needs a grant, but the eNB only hands out grants when it knows the UE actually has something to send, how much of it there is, and whether the UE can reach the cell with enough power. Downlink is easy by comparison — the eNB owns the buffers and knows exactly what it wants to transmit. Uplink is opaque: the data and the power budget both live in the UE. SR, BSR and PHR are the feedback that lets the scheduler act on fact instead of guesswork.

These three reports are not independent trivia — they form a pipeline. A BSR that has been triggered but has no PUSCH resource to travel on will itself trigger an SR; the SR wins a small grant; that grant carries the BSR; the BSR earns a right-sized grant; and the data PUSCH that follows can piggyback a PHR. Understanding the trio means understanding how each report hands off to the next.

Scheduling Request (SR)

The SR is the smallest signal in the whole system — a single bit — but it starts the entire uplink loop. When data arrives for a logical channel and the UE holds no valid uplink grant to send it on, the MAC entity triggers an SR. There is nowhere to put a BSR yet, so the UE must first raise its hand with the one-bit ask.

The SR travels on PUCCH format 1/1a/1b as a single bit; the eNB's answer is a small uplink grant delivered as a DCI format 0 on PDCCH, CRC scrambled with the UE's C-RNTI, in the UE-specific search space. There is no separate "SR-RNTI" — the SR resource itself is UE-specific, so the eNB knows which UE asked purely from which PUCCH resource carried the bit.

The two SR timers and counters

Two RRC parameters govern how an SR behaves once triggered. The sr-ProhibitTimer is a rate limiter: after the UE transmits an SR, it must not send another until the prohibit timer expires, even if further SR occasions arrive in the meantime. This stops the UE spraying repeated one-bit requests while the eNB is still processing the first one. The dsr-TransMax counter, by contrast, is a give-up threshold: the MAC maintains an SR_COUNTER, incrementing it each time an SR is actually transmitted, and once the counter reaches dsr-TransMax the UE stops trying the D-SR path entirely, releases its PUCCH/SRS configurations, clears any downlink assignment and uplink grant, and initiates Random Access.

The RA-SR fallback

Not every UE always has a dedicated SR resource. If the UE has data to send but holds no configured D-SR PUCCH resource (and no grant), it cannot send a one-bit ask at all — so it goes straight to the Random Access procedure as its scheduling request. This is the RA-SR (random-access SR) path. The same fallback catches the UE that did have a D-SR resource but exhausted dsr-TransMax attempts without a grant. In both cases the RACH preamble becomes the request, Msg2 (the Random Access Response) carries the initial UL grant, and Msg3 then carries the BSR — Random Access substitutes for the missing or failed D-SR.

Reading the SR step in the logs

On the UE side the SR event shows when the bit was triggered, which resource carried it, the running SR_COUNTER, and whether a grant came back before dsr-TransMax. This is usually the first line you check for a "UE won't send uplink" ticket.

Representative UE MAC log (QXDM/QCAT-style) — illustrative, values vary by vendor/build:

Buffer Status Report (BSR)

Once the UE has a grant, it tells the eNB how much data it has. The BSR is a MAC CE that reports the amount of buffered data, aggregated per Logical Channel Group (LCG). LTE defines exactly 4 LCGs (LCG ID 0–3), so the many logical channels a UE may run are bucketed into a handful of groups to keep the report compact. Each radio bearer is mapped to one LCG by RRC through the logicalChannelGroup field in its logical channel configuration, and grouping is usually by priority class — for example signalling and voice in low-numbered, high-priority groups, best-effort data in another.

Short, Long and Truncated BSR

Because the report has to fit whatever grant is available, LTE defines three BSR formats. Each is a distinct MAC CE with its own LCID in the subheader, so the eNB knows from the header alone which format it is parsing.

The Short and Truncated formats look identical on the wire — both are one LCG ID plus one buffer-size index — but they mean different things and use different LCID values. A Short BSR says "only this one group has data"; a Truncated BSR says "several groups have data, but there was only room to tell you about the most urgent one." That distinction lets the eNB know more grants are probably coming.

The 6-bit buffer-size index

The buffer size is never sent as a raw byte count. Instead each LCG's buffered volume is quantised to a 6-bit index into a buffer-size table — 64 levels (indices 0–63) spanning from 0 bytes up to tens of kilobytes on a roughly logarithmic scale. The eNB reads the index, looks up the byte range it represents, and sizes the next grant accordingly. Because the mapping is coarse and each index represents a range, the eNB tends to round up, which is why a couple of BSR rounds are sometimes needed to drain a large burst cleanly.

The exact byte boundaries live in the buffer-size tables of TS 36.321; the concept to carry away is the logarithmic quantisation: precise for tiny buffers, coarse for huge ones, always erring toward over-grant rather than starving the UE.

What triggers a BSR

A subtlety of the Regular trigger: it fires only when higher-priority data arrives or when the buffers were previously empty — not for every byte that lands in an already-busy lower-priority queue. That keeps regular BSRs meaningful (a genuine change in the priority picture) rather than constant. The Regular and Periodic triggers are the ones that can, in turn, trigger an SR; a Padding BSR never does, because by definition it only exists when there is already a grant to ride on.

Reading the BSR step in the logs

The BSR trace shows the format, which LCGs reported, the 6-bit index per group, and the grant the eNB issued in response. Comparing the reported index against the next grant size is the fastest way to tell whether the eNB believed the buffer report.

Representative UE MAC log — illustrative, values vary by vendor/build:

Power Headroom Report (PHR)

Knowing how much data to schedule is not enough — the eNB also needs to know whether the UE can physically power the transmission. The PHR is a MAC CE reporting the difference between the UE's configured maximum transmit power and the power it would currently need for its PUSCH. It turns the UE's power budget, otherwise invisible to the network, into a number the scheduler can plan against.

A positive headroom means the UE has room to spare and can be scheduled a wider or higher-MCS allocation. A negative value means the UE is already power-limited — it wanted more power than PCMAX,c allows and is transmitting at its ceiling — so the eNB should be conservative with the RB allocation. The value is quantised into a power-headroom range and reported against the reference PCMAX,c, and it is only ever sent when the UE actually has a PUSCH transmission to piggyback it on.

Extended and Dual-Connectivity PHR

The single-value PHR describes one carrier. LTE-Advanced added carrier aggregation, so a UE can transmit on several serving cells at once and the eNB needs a headroom figure for each. The Extended PHR MAC CE handles this: it carries a bitmap indicating which activated serving cells are being reported, followed by a Type 1 PH entry (and its PCMAX,c) for each cell flagged in the bitmap. That way one report covers the whole aggregated uplink.

Dual Connectivity (a UE connected to a Master eNB and a Secondary eNB simultaneously) pushed this further with the Dual-Connectivity PHR. Because the two cell groups — the Master Cell Group (MCG) and Secondary Cell Group (SCG) — schedule independently, the DC PHR reports headroom across the cells of both groups so each scheduler has a coherent view. It also reports both a real PH (for cells the UE is actually transmitting on) and a virtual PH (a reference-based estimate for cells it is not currently transmitting on), so the network can plan allocations on cells that are configured but idle.

What triggers a PHR

Reading the PHR step in the logs

The PHR trace shows the trigger, the reported headroom value (or per-cell values for Extended/DC PHR), and the reference PCMAX,c. A persistently negative headroom is the tell-tale of a power-limited cell-edge UE that the scheduler should not push harder.

Representative UE MAC log — illustrative, values vary by vendor/build:

Putting It Together — SR → Grant → BSR → Right-Sized Grant

In a cold start — data arrives while the UE holds no grant — the three reports chain into the uplink scheduling loop. The SR buys a foothold, the BSR quantifies the need, and the PHR rides along on the data that follows.

If the UE already holds a grant when data arrives, it skips the SR entirely and sends the BSR straight away — the request step only exists to break the deadlock of having data but no way to describe it. When a periodic timer fires, or a grant has spare padding, a BSR or PHR can hitch a ride with no explicit request at all. And when the D-SR path is missing or exhausted, the whole sequence simply begins one step earlier, at Random Access, with Msg3 carrying the first BSR.

The reason the loop needs two grants — a small one then a right-sized one — is that the eNB genuinely does not know the buffer volume until the BSR arrives. The first grant is a deliberately cheap probe just big enough to carry a BSR; only once the eNB reads the buffer-size indices can it allocate resource blocks proportional to the actual need, factoring in the PHR so it never grants more than the UE can power.

Summary and Quick Q&A

The trio divides one hard question — "how should I schedule this UE's uplink?" — into three answerable pieces. SR answers when with a single bit on PUCCH, bounded by sr-ProhibitTimer and dsr-TransMax with Random Access as the fallback. BSR answers how much with a per-LCG report in Short, Long or Truncated form, quantised through the 6-bit buffer-size index and triggered as Regular, Periodic or Padding. PHR answers can you power it with a Type 1 headroom value — extended across carriers for CA and across cell groups for Dual Connectivity — triggered by periodicPHR-Timer, by a dl-PathlossChange beyond threshold once prohibitPHR-Timer allows, or by (re)configuration.

To root-cause an uplink stall, walk the chain in order: did the SR get a grant? Did the BSR's reported index produce a right-sized grant? Did the PHR reveal the UE is power-limited? The first handoff that breaks tells you where — and usually why — the uplink stopped.