🧩 MAC — Medium Access ControlIntermediate

BSR, PHR & Scheduling Request in 5G NR

How the UE tells the gNB what it has to send (BSR/SR) and how much power it has (PHR).

📚 3GPP-basedTS 38.321

For the downlink, the gNB is both the source of the data and the scheduler. It knows exactly how many bytes are queued for each UE, exactly what its own transmit power is, and exactly when it wants to send. Uplink scheduling has none of that. The data is in the UE, the power amplifier is in the UE, and the gNB has to allocate resource before it can be told anything about either.

Contents

01Three Questions the Network Cannot Answer for Itself
02Scheduling Request: One Bit, and What It Buys
03The SR Counter, the Prohibit Timer, and Falling Back to RACH
04Buffer Status Reporting: Logical Channel Groups
05The Four BSR Formats
06The Buffer Size Level Tables
07BSR Triggers and Format Selection
08The BSR Timers
09Power Headroom: What the Scheduler Does With It
10Type 1, Type 2 and Type 3; Real and Virtual
11The PHR Control Elements, Bit by Bit
12PHR Triggers
13Worked Arithmetic
14How the Three Mechanisms Work Together
15Configuration Reference (ASN.1 and Ranges)
16Timers and Counters
17Failure Modes and What Each One Means
18Illustrative Message Traces
19Release Deltas: Rel-15 to Rel-18
20Reading BSR, PHR and SR in Logs: a Checklist
21Glossary
22References

1. Three Questions the Network Cannot Answer for Itself

So NR gives the UE three ways to inform the scheduler, deliberately asymmetric in cost and in information content:

Mechanism	Question it answers	Carried on	Size	Cost of being wrong
SR -- Scheduling Request	"I have something to send and no way to send it."	A dedicated PUCCH resource; Random Access as fallback	One bit -- literally. Present or absent	The UE waits for the next SR occasion, so the cost is latency: half the SR period on average, and the whole period at worst
BSR -- Buffer Status Report	"Here is how much I have queued, per logical channel group."	A MAC CE, so it needs a grant to travel on	1 octet (Short) to 9 octets (Long, all eight groups), plus a subheader	The scheduler mis-sizes every subsequent grant. Too small and the buffer never drains; too large and the transport block goes out full of padding
PHR -- Power Headroom Report	"Here is how much more transmit power I could have used."	A MAC CE	2 octets (Single Entry) to a few tens (Multiple Entry with many carriers)	The scheduler picks an MCS or PRB count the UE cannot actually transmit, so the transport block fails decoding and HARQ burns retransmissions on a link that was never going to work

Table 1. The three uplink feedback mechanisms. Note the ordering: SR is the cheapest and least informative, PHR the most expensive and the slowest-changing.

💡

Key Point

The three form a chain, and the chain matters. An SR gets you a grant. The grant is small, because the gNB knows nothing about volume, so the first thing the UE puts in it is a BSR. The BSR gets you a properly sized grant -- but the shape of that grant, the MCS and the number of PRBs, is bounded by the last PHR. Break any link and the symptom appears somewhere else in the chain: an SR problem looks like latency, a BSR problem looks like throughput, a PHR problem looks like uplink HARQ failures.

All three are MAC procedures with no RRC involvement per report, which is what makes them fast enough to be useful. See the companion 07 MAC PDU and Control Elements document for the general control element framework, and 09 LCP for how the reports compete with data for room in a grant.

2. Scheduling Request: One Bit, and What It Buys

An SR carries no information beyond its own existence. There is no size field, no logical channel identity, no urgency indication -- the UE either transmits on its SR PUCCH occasion or it does not, and the gNB reads "this UE wants a grant". Everything else has to wait for the BSR that the resulting grant carries.

That minimalism is the point. An SR occasion is one or two PUCCH symbols; a cell can afford to give every connected UE a recurring occasion every few milliseconds. Anything richer would not fit in that budget, and the UE would have to wait for a grant to say anything at all -- which is exactly the deadlock SR exists to break.

2.1 SR resources

SR resources are configured in two layers. A SchedulingRequestConfig defines the behaviour -- how many attempts, how fast -- and is identified by a schedulingRequestId. A SchedulingRequestResourceConfig defines the occasions -- which PUCCH resource, at what periodicity and offset -- and points at a schedulingRequestID. Several resource configurations may point at the same SR configuration, which is how a UE can have SR occasions on several BWPs or several cells for one logical SR.

Field	Where	Range	Typical	Effect
schedulingRequestId	SchedulingRequestToAddMod	0 – 7	0	Names one SR configuration. A logical channel selects it with `schedulingRequestID` in `LogicalChannelConfig`
sr-ProhibitTimer	SchedulingRequestToAddMod	ms1, ms2, ms4, ms8, ms16, ms32, ms64, ms128; absent = 0	absent or ms1-ms8	Minimum gap between SR transmissions on this configuration. Absent means the UE may use every occasion
sr-TransMax	SchedulingRequestToAddMod	n4, n8, n16, n32, n64	n8 or n16	How many SR transmissions before the UE gives up and starts Random Access
schedulingRequestResourceId	SchedulingRequestResourceConfig	1 – 64	--	Names one set of SR occasions
periodicityAndOffset	SchedulingRequestResourceConfig	sym2, sym6or7, sl1, sl2, sl4, sl5, sl8, sl10, sl16, sl20, sl40, sl80, sl160, sl320, sl640, each with an offset	sl10 or sl20 for eMBB, sym2 for URLLC	The single largest term in uplink access latency. See the worked budget in §13.3
resource	SchedulingRequestResourceConfig	PUCCH-ResourceId	--	Which PUCCH resource carries the SR. Format 0 (1-2 symbols) or format 1 (4-14 symbols)
schedulingRequestID	LogicalChannelConfig	0 – 7	0	Which SR configuration this logical channel triggers. Absent means the channel has no SR at all and falls straight to Random Access
logicalChannelSR-Mask	LogicalChannelConfig	BOOLEAN	false	When true, this channel does not trigger an SR while a configured grant is available

Table 2. SR configuration, TS 38.331 SchedulingRequestConfig and SchedulingRequestResourceConfig. sym2 and sym6or7 are sub-slot periodicities and exist only for latency-critical traffic.

⚠️

Common Pitfall

periodicityAndOffset is expressed in slots (or symbols), not milliseconds, so its wall-clock meaning depends on the numerology. sl20 is 20 ms at 15 kHz, 10 ms at 30 kHz and 2.5 ms at 120 kHz. A configuration copied between bands without adjustment changes the uplink latency by a factor of eight and nothing warns you.

2.2 What triggers an SR

An SR is not triggered by data arriving. It is triggered by a Regular BSR that has nowhere to go TS 38.321 cl. 5.4.4. If a Regular BSR is triggered and the UE has no uplink grant in which to send it, the UE triggers an SR for the SR configuration of the logical channel that caused the BSR. If that channel has logicalChannelSR-DelayTimerApplied set, the SR is held back until logicalChannelSR-DelayTimer expires -- deliberately, to let more data accumulate and avoid an SR per packet on a trickle flow.

Rel-16 added two more SR-like triggers with their own SR configurations: schedulingRequestID-BFR-SCell for SCell beam failure recovery and schedulingRequestID-LBT-SCell for consistent LBT failure on an unlicensed SCell. Both exist so a UE that needs to send a recovery MAC CE can ask for a grant without competing with ordinary data SRs.

3. The SR Counter, the Prohibit Timer, and Falling Back to RACH

Figure 1. The full sequence, and the failure path. Everything below the divider is the same UE when nothing ever answers.

Each SR configuration has its own counter, SR_COUNTER. The procedure is short enough to state completely TS 38.321 cl. 5.4.4:

1. A pending SR exists, sr-ProhibitTimer is not running, and an SR occasion for the relevant configuration arrives. The UE checks SR_COUNTER against sr-TransMax.

2. If SR_COUNTER < sr-TransMax: transmit the SR on PUCCH, increment SR_COUNTER, and start sr-ProhibitTimer.

3. If SR_COUNTER = sr-TransMax: do not transmit. Instead notify RRC to release PUCCH for all serving cells, release SRS for all serving cells, clear any configured downlink assignments and uplink grants, clear any PUSCH resource for semi-persistent CSI reporting, initiate a Random Access procedure on the SpCell, and cancel all pending SRs.

4. A pending SR is cancelled when a MAC PDU is assembled containing a BSR that covers the buffer status up to and including the event that triggered it, or when the uplink grant can accommodate all the pending data.

💡

Key Point

Read step 3 again. Reaching sr-TransMax does not just retry -- it tears down the UE's entire uplink control configuration: PUCCH gone, SRS gone, configured grants gone, SP-CSI gone. After the Random Access completes, all of that has to be re-established by RRC. In a log this looks like a UE that inexplicably reappears on RACH with no radio problem and no handover, and the only evidence of why is a run of SR transmissions several tens of milliseconds earlier.

Situation	sr-ProhibitTimer	SR_COUNTER	What actually happens
First SR after a Regular BSR	not running	0 -> 1	SR transmitted on the next occasion; timer started
Next occasion arrives, timer still running	running	unchanged	No SR is sent. The occasion is skipped entirely
Timer expires, still no grant	expired	1 -> 2	SR transmitted on the next occasion; timer restarted
A grant arrives that can carry the BSR	any	reset to 0	SR cancelled once the BSR is in an assembled MAC PDU
A grant arrives that accommodates all pending data	any	reset to 0	SR cancelled -- no BSR is even needed, because there is nothing left to report
`SR_COUNTER` reaches `sr-TransMax`	irrelevant	at maximum	PUCCH/SRS/configured grants released, Random Access initiated on the SpCell

Table 3. SR state transitions. The second row is the one that surprises people: sr-ProhibitTimer causes SR occasions to be silently skipped, so the effective SR period is the configured period plus the prohibit time.

🧮

Worked Calculation

The effective worst-case time between SR attempts is sr-ProhibitTimer rounded up to the next SR occasion, not the SR periodicity. With periodicityAndOffset = sl20 at 30 kHz (10 ms) and sr-ProhibitTimer = ms16, the second attempt cannot happen until 20 ms after the first: 16 ms of prohibition, then wait to the 20 ms occasion. Eight attempts at sr-TransMax = n8 therefore take about 150 ms before the UE gives up. A UE that appears to hang for 150 ms and then does RACH is following the spec exactly.

3.1 Why RACH is the fallback

Random Access is the one uplink procedure that needs no prior configuration and no grant. It is the bootstrap for a UE with no identity, and it works equally well as the bootstrap for a UE whose control channel has stopped being answered. The C-RNTI MAC CE in MSG3 tells the gNB which UE this is -- see the companion 03 Random Access document, and 07 MAC PDU and Control Elements for the CE itself. A logical channel with no schedulingRequestID at all goes straight here the first time it has data and no grant.

4. Buffer Status Reporting: Logical Channel Groups

A UE can have up to 32 logical channels per MAC entity. Reporting a buffer size for each would cost 32 octets plus a bitmap -- more than the small grants a BSR typically travels in. So logical channels are collected into at most eight logical channel groups by logicalChannelGroup (0..7) in LogicalChannelConfig, and the BSR reports per group.

Figure 2. The grouping and what it costs. Grouping loses exactly one thing: the distinction between channels inside a group.

The compression is lossy in a specific and consequential way. Within a group, the scheduler cannot tell urgent data from bulk data, so it cannot prioritise between them -- it can only grant a total. Between groups it can, because each group has its own number and (in most implementations) its own notion of priority derived from the highest-priority channel it contains.

⚠️

Common Pitfall

Group assignment is the single highest-leverage BSR configuration decision, and it is almost always left at whatever the bearer template shipped with. The rule of thumb: channels that would ever need different scheduling treatment must not share a group. Voice and a background upload in one LCG means the scheduler sees one buffer that is sometimes urgent, and it will either over-grant for the bulk or under-grant for the voice. There are eight groups; using three of them is leaving capability on the table.

LCG	Commonly carries	Why it is grouped that way
0	SRB1, SRB2, and often the IMS signalling DRB	Signalling is low-volume, high-priority, and delay-sensitive in a way no data bearer is. Keeping it alone means a signalling burst always reads as urgent
1	Conversational voice (5QI 1), conversational video (5QI 2)	Constant-rate, small, delay-critical. A number here means "grant soon, grant small"
2	Interactive and streaming data (5QI 6, 7, 8)	Bursty and moderately delay-sensitive
3	Default bearer, background traffic (5QI 9)	Large and delay-tolerant. A number here means "grant when there is spare capacity"
4 – 7	Often unused; URLLC bearers, network slices, or per-slice separation	Rel-16 slice-aware scheduling makes these worth using: a slice with its own SLA benefits from its own LCG

Table 4. A representative LCG assignment. Nothing in the specs mandates any of this -- it is entirely an operator and vendor choice, which is why it varies so much between networks.

5. The Four BSR Formats

Figure 3. All four formats. The two short ones are the same octet and are told apart only by the LCID in the subheader.

Format	LCID	Size	Buffer Size index width	Reports
Short BSR	UL 61	1 octet	5 bits, 32 levels	One LCG's buffer size, and implicitly that no other group has data
Short Truncated BSR	UL 59	1 octet	5 bits, 32 levels	One LCG's buffer size, with the explicit meaning that other groups also have data that is not being reported
Long BSR	UL 62	1 octet bitmap + 1 octet per reported LCG; 2 to 9 octets	8 bits, 256 levels	Every LCG with data. The bitmap says which, the octets say how much
Long Truncated BSR	UL 60	1 octet bitmap + as many Buffer Size octets as fit	8 bits, 256 levels	The bitmap still shows every LCG with data; only some of them get a size

Table 5. BSR formats, TS 38.321 cl. 6.1.3.1. The Long formats use a different, finer quantisation table than the Short ones -- see §6.

The bitmap is `LCG_7` down to `LCG_0`, one bit per group, bit i for LCG i. A set bit means that group has data available for transmission.
Buffer Size fields follow in ascending LCG order in a Long BSR, one per set bit. In a Long Truncated BSR the bitmap is unchanged but fewer fields are present, and the groups that get a field are chosen by the priority of the highest-priority logical channel each group contains.
The reported value is the buffer after this PDU. All BSRs describe the buffer as it will be once the MAC PDU carrying the BSR has left, which is why uplink control elements are placed after the SDUs in the PDU -- see the companion 07 MAC PDU and Control Elements document.

📘

Spec Detail

A Long Truncated BSR is more informative than it looks, and more informative than a Short Truncated BSR. Its bitmap still lists every group with data, so the scheduler learns which groups are active even when it does not learn how much each holds. That is usually enough to grant something sensible. The Short Truncated BSR gives one group and one number and no indication of how many others were suppressed.

6. The Buffer Size Level Tables

Buffer sizes are not reported in octets. They are reported as an index into a table of geometrically spaced levels, because a scheduler needs byte-level precision at 40 octets and does not need it at 40 kilobytes. Index n means "the buffer is greater than level n−1 and at most level n"; index 0 means the buffer is empty.

6.1 The 5-bit table -- Short BSR and Short Truncated BSR

Index	Buffer size (octets)	Index	Buffer size (octets)
0	BS = 0	16	1 038 < BS <= 1 446
1	0 < BS <= 10	17	1 446 < BS <= 2 014
2	10 < BS <= 14	18	2 014 < BS <= 2 806
3	14 < BS <= 20	19	2 806 < BS <= 3 909
4	20 < BS <= 28	20	3 909 < BS <= 5 446
5	28 < BS <= 38	21	5 446 < BS <= 7 587
6	38 < BS <= 53	22	7 587 < BS <= 10 570
7	53 < BS <= 74	23	10 570 < BS <= 14 726
8	74 < BS <= 102	24	14 726 < BS <= 20 516
9	102 < BS <= 142	25	20 516 < BS <= 28 581
10	142 < BS <= 198	26	28 581 < BS <= 39 818
11	198 < BS <= 276	27	39 818 < BS <= 55 474
12	276 < BS <= 384	28	55 474 < BS <= 77 284
13	384 < BS <= 535	29	77 284 < BS <= 107 669
14	535 < BS <= 745	30	107 669 < BS <= 150 000
15	745 < BS <= 1 038	31	BS > 150 000

Table 6. Buffer size levels for the 5-bit Buffer Size field, TS 38.321 Table 6.1.3.1-1. Complete -- all 32 codepoints.

🧮

Worked Calculation

The spacing is exactly geometric. From level 1 (10 octets) to level 30 (150 000 octets) is 29 steps:

ratio r = (150 000 / 10)^(1/29) = 15 000^(1/29) = 1.393

Check a few: 10 x 1.393 = 13.9 -> 14; 74 x 1.393 = 103 -> 102; 107 669 x 1.393 = 149 973 -> 150 000.

So every level is about 39% larger than the one below it, and the relative uncertainty of a report is constant:

uncertainty = (r − 1) / r = 0.393 / 1.393 = 28% of the reported value, at every scale.

That is the design intent: a Short BSR is always accurate to within about a quarter, whether the buffer holds 100 octets or 100 kilobytes.

6.2 The 8-bit table -- Long BSR and Long Truncated BSR

The Long formats spend a whole octet per group, so they use a 256-level table with the same top and bottom shape and a much finer ratio.

Index	Buffer size (octets)	Note
0	BS = 0	Empty. Used to tell the scheduler a group has drained
1	0 < BS <= 10	Same bottom of scale as the 5-bit table
2	10 < BS <= 11	One octet of resolution at the low end
3	11 < BS <= 12	--
4	12 < BS <= 13	--
5	13 < BS <= 14	The 5-bit table's level 2 is already here
...	geometric with ratio r ~ 1.065	Roughly 6% relative uncertainty throughout, against 28% for the 5-bit table
254	BS <= 81 338 368	About 81 MB -- the largest bounded level
255	BS > 81 338 368	The top codepoint. It means "more than 81 MB" and nothing more precise; it is a saturation indicator, not a measurement

Table 7. Buffer size levels for the 8-bit Buffer Size field, TS 38.321 Table 6.1.3.1-2, abridged. Intermediate levels follow the geometric law; read the exact values from the table rather than computing them, because the spec rounds each level independently.

⚠️

Common Pitfall

What the top codepoint means, and why it matters. Index 31 of the 5-bit table means "more than 150 000 octets" -- and that is all it will ever mean, no matter whether the UE has 200 kB or 200 MB queued. A UE uploading a large file reports 31 for the entire upload, so the scheduler gets no gradient at all until the buffer finally falls below 150 kB. Uplink schedulers that ramp based on changes in reported buffer size go flat during exactly the traffic that most needs capacity. The 8-bit table pushes the saturation point out to about 81 MB, which is why a Long BSR is worth its extra octets on any bearer that carries bulk data.

7. BSR Triggers and Format Selection

There are three kinds of BSR and they are distinguished by what caused them, not by what they contain TS 38.321 cl. 5.4.5.

Kind	Trigger condition	Priority against data	Effect on timers
Regular BSR	UL data becomes available for a logical channel belonging to an LCG, and either that channel has higher priority than any channel with data in any LCG, or no channel in any LCG had any data at all	Above all logical channel data (rank 6 of the CE priority list)	Triggers an SR if there is no grant to send it on. Restarts `periodicBSR-Timer` when transmitted
Regular BSR (retransmission)	`retxBSR-Timer` expires and at least one channel in an LCG has data	Same	The safety net: a BSR was sent, a grant never followed, and the UE asks again
Periodic BSR	`periodicBSR-Timer` expires	Same as Regular	Restarts `periodicBSR-Timer`. Does not trigger an SR
Padding BSR	Uplink resources are allocated and the padding remaining after the MAC PDU has been built is at least the size of a Short BSR plus its subheader (2 octets)	Below all logical channel data (rank 15, last)	Does not restart `periodicBSR-Timer` if it is a truncated format. Costs nothing, because it uses octets that would have been padding

Table 8. BSR triggers. The two conditions on a Regular BSR are worth reading carefully -- data arriving on a lower-priority channel when higher-priority data is already queued triggers nothing at all.

💡

Key Point

The Regular BSR trigger is edge-triggered, not level-triggered. Data arriving on a logical channel while a higher-priority channel already has data queued does not trigger a Regular BSR, because the scheduler's picture of what is most urgent has not changed. The new data reaches the network's attention only via the next Periodic BSR, a padding BSR, or retxBSR-Timer. This is correct and efficient, and it is also why periodicBSR-Timer values above about 40 ms produce visible latency on bursty low-priority bearers.

Figure 4. Format selection. The trigger decides whether a BSR is included; the space available decides which of the four formats it is.

One rule that follows from the diagram and is easy to miss: if only one LCG has data, the answer is always a Short BSR, whatever the trigger and however much room there is. A single octet says everything there is to say, so there is nothing for the longer formats to add.

8. The BSR Timers

Figure 5. The three timers on one axis. Note the 8 ms between the trigger and the first SR occasion -- pure periodicity, and larger than everything else in the sequence.

Timer	Started / restarted when	On expiry	Range	Typical
periodicBSR-Timer	A BSR (other than a truncated one) is transmitted	A Periodic BSR is triggered	sf1, sf5, sf10, sf16, sf20, sf32, sf40, sf64, sf80, sf128, sf160, sf320, sf640, sf1280, sf2560, infinity	sf10 – sf20
retxBSR-Timer	A grant for a new transmission on any UL-SCH is received	A Regular BSR is triggered if any LCG has data	sf10, sf20, sf40, sf80, sf160, sf320, sf640, sf1280, sf2560, sf5120, sf10240	sf80 – sf320
logicalChannelSR-DelayTimer	A Regular BSR is triggered by a channel with `logicalChannelSR-DelayTimerApplied` = true	The SR that the Regular BSR would have triggered is now allowed	sf20, sf40, sf64, sf128, sf512, sf1024, sf2560	absent
sr-ProhibitTimer	An SR is transmitted	The next SR occasion may be used	ms1, ms2, ms4, ms8, ms16, ms32, ms64, ms128	absent – ms8

Table 9. The four timers around BSR and SR. sf is subframes, i.e. milliseconds, independent of numerology; periodicityAndOffset for SR resources is in slots, which is not.

retxBSR-Timer deserves more attention than it usually gets. It is not a BSR retransmission timer in the ordinary sense -- it is a deadlock detector. The UE restarts it every time it receives a grant for new data. If it ever expires while data is still buffered, that means the network stopped granting while the UE still had something to send, which should not happen if the last BSR was received. So the UE assumes the BSR was lost and triggers a fresh Regular BSR -- which, if there is still no grant, triggers a fresh SR.

⚠️

Common Pitfall

retxBSR-Timer set too long is one of the quietest performance faults in NR. With sf2560 (2.56 s), a single lost BSR on a bearer whose Regular BSR trigger will not fire again -- because higher-priority data is already queued -- stalls that bearer for over two seconds with no error, no retransmission and no counter anywhere. sf80 to sf320 bounds the damage to a value that looks like jitter rather than a hang.

📘

Spec Detail

periodicBSR-Timer = infinity is a legal and occasionally deliberate configuration: it disables Periodic BSR entirely and leaves the network dependent on Regular BSRs and padding BSRs. On a UE with a single active bearer that is fine. On a UE with several LCGs it means the scheduler's view of the lower-priority groups is refreshed only by padding BSRs, which arrive only when a grant happens to have spare octets -- so it is refreshed most rarely exactly when the cell is busiest.

9. Power Headroom: What the Scheduler Does With It

Uplink transmit power is not a free variable. It is determined by an open and closed loop formula TS 38.213 cl. 7.7 whose terms include the number of PRBs allocated and the modulation and coding scheme -- both of which the scheduler chooses. So the scheduler is choosing the UE's transmit power without being able to measure it, and if it chooses badly the UE clips at P_CMAX and the transport block arrives under-powered.

Power headroom is the difference, in dB, between the UE's configured maximum output power and the power its current transmission actually required:

Type 1 power headroom, TS 38.213 cl. 7.7.1

PH_type1,f,c  =  P_CMAX,f,c  -  {  P_O_PUSCH,f,c(j)
                                 + 10 log10( 2^mu  x  M_RB,f,c(i) )
                                 + alpha_f,c(j)  x  PL_f,c(q_d)
                                 + DELTA_TF,f,c(i)
                                 + f_f,c(i,l)            }      [dB]

  P_CMAX,f,c   UE configured maximum output power for carrier f, cell c
  P_O_PUSCH    open-loop target: nominal + UE-specific component
  M_RB         number of PRBs allocated for this PUSCH
  mu           numerology (0 = 15 kHz, 1 = 30 kHz, ...)
  alpha        fractional pathloss compensation factor, 0 .. 1
  PL           downlink pathloss estimate from the reference RS
  DELTA_TF     transport-format-dependent offset (spectral efficiency)
  f            closed-loop accumulated TPC correction

The important structural fact is the 10 log10(2^mu x M_RB) term. Headroom is not a property of the UE alone -- it depends on how many PRBs the scheduler gave it. Doubling the PRB count costs 3 dB of headroom. That is the whole reason PHR exists: it lets the scheduler work out, from one report, how much more bandwidth this UE could support.

💡

Key Point

A negative power headroom is legal, meaningful and common. It means the formula asked for more power than P_CMAX allows, so the UE transmitted at P_CMAX and the transmission was short of its target by that many dB. The correct scheduler response is to reduce the PRB count or the MCS, not to retry -- HARQ retransmissions of an under-powered block at the same size will fail the same way. In a log, a run of uplink HARQ failures with a negative PHR is not a coverage mystery; it is an over-allocation.

10. Type 1, Type 2 and Type 3; Real and Virtual

Type	Measures headroom for	Where it appears	Release
Type 1	A PUSCH transmission	Every PHR. The Single Entry PHR is always Type 1; a Multiple Entry PHR carries one Type 1 entry per reported serving cell	Rel-15
Type 2	A combined PUSCH and PUCCH transmission	Only for the SpCell of the other cell group in EN-DC or NR-DC, and only when `phr-Type2OtherCell` is true	Rel-15
Type 3	An SRS transmission	For a serving cell configured for SRS carrier switching, where the UE transmits SRS but no PUSCH	Rel-16

Table 10. Power headroom types. Type 3 exists because a carrier can be SRS-only -- it is sounded so the scheduler can evaluate it, without ever carrying data.

Cutting across the types is a second distinction that changes both the meaning and the length of the report:

Real (V = 0): the UE actually transmitted on that carrier in the relevant occasion, so the reported headroom is measured from a genuine transmission with a genuine PRB count and MCS. The octet carrying P_CMAX,f,c is present.
Virtual (V = 1): the UE was not transmitting on that carrier, so it computes the headroom it would have had for a reference format -- one PRB, no transport-format offset, and the current closed-loop value. The P_CMAX,f,c octet is omitted, making the entry one octet instead of two.

⚠️

Common Pitfall

A virtual PHR is not a worse version of a real one -- it answers a different question. Because it assumes a single PRB and no format offset, it is essentially a pathloss report: it tells the scheduler how much power the UE would need for a minimal transmission on that carrier, which is exactly what you want to know before activating a carrier the UE has never used. Treating a large virtual PH as "plenty of headroom, allocate freely" is the classic misreading -- the number was computed for one PRB, and 100 PRBs costs 20 dB more.

The P bit is separate again. It indicates that the UE applied power backoff for power-management reasons -- specific absorption rate limits, thermal limits, or a P-MPR allowance -- so P_CMAX,f,c for that occasion was lower than the UE's nominal capability. A P bit set on repeated reports from a handset held against a body is normal; a P bit set on a fixed-wireless terminal is worth investigating.

11. The PHR Control Elements, Bit by Bit

11.1 Single Entry PHR

Figure 6. Two octets, no conditional fields. This is the format used when only one serving cell has an uplink configured, or when multiplePHR is false.

11.2 Multiple Entry PHR

Figure 7. A bitmap and then a variable number of entries, each one or two octets depending on its own V bit. The parse depends on the payload, which is unique among MAC control elements.

The entry order is fixed: the Type 2 entry for the other cell group's SpCell first if phr-Type2OtherCell is set, then the Type 1 entry for the PCell, then one entry per activated serving cell whose C-bit is set, in ascending ServCellIndex order. There is no C0 bit because the PCell entry is unconditional.

Field	Bits	Values	Meaning
Ci	1 per serving cell	1 = an entry for serving cell i is present	One-octet bitmap (LCID 56) covers `ServCellIndex` 1-7; four-octet bitmap (LCID 54) covers 1-31
P	1	0 or 1	1 = the UE applied power backoff for power-management reasons, so `P_CMAX,f,c` for this occasion is below the UE's nominal maximum
V	1	0 = real, 1 = virtual	Also decides length: V = 0 means a `P_CMAX,f,c` octet follows, V = 1 means it does not
PH	6	0 – 63	Index into the power headroom reporting range of TS 38.133. The range spans roughly −32 dB to +38 dB, with 1 dB granularity across most of it and coarser steps at both extremes
P_CMAX,f,c	6	0 – 63	Index into the `P_CMAX,f,c` reporting range of TS 38.133, spanning approximately −29 dBm to +33 dBm in 1 dB steps. Present only when V = 0
R	1 or 2	0	Reserved

Table 11. PHR fields, TS 38.321 cl. 6.1.3.8 and 6.1.3.9. The dB and dBm endpoints are the reporting range boundaries; take the exact index-to-value mapping from the TS 38.133 tables rather than assuming a linear scale, because the step size is not uniform across the PH range.

📘

Spec Detail

The reason a PHR carries P_CMAX,f,c at all -- and the reason it is a reported field rather than something the network already knows -- is that P_CMAX,f,c is not constant. It varies with the band, the channel bandwidth, the waveform, the number of simultaneously transmitting carriers, and any power-management backoff the UE applied. A headroom figure without the ceiling it was measured from is not actionable, which is why the two travel together and why a virtual entry -- which omits the ceiling -- must be read as a pathloss indication rather than a capacity one.

12. PHR Triggers

Trigger	Condition	Gated by	Why
Pathloss change	The pathloss for at least one activated serving cell used as a pathloss reference has changed by more than `phr-Tx-PowerFactorChange` dB since the last PHR	`phr-ProhibitTimer` must have expired	The scheduler's power model has gone stale. This is the trigger that matters when a UE is moving
Periodic	`phr-PeriodicTimer` expires	Nothing	Refreshes the model even when nothing changed, so a lost report is not permanent
Configuration	Power headroom reporting is configured or reconfigured by upper layers	Nothing	The network asked for the function; it gets a first report immediately
SCell activation	An SCell of any MAC entity with a configured uplink is activated	Nothing	A new carrier has appeared and the scheduler has no headroom figure for it at all -- often a virtual one, because the UE has not transmitted there yet
PSCell addition	A PSCell is added (NR-DC or EN-DC)	Nothing	Same argument, plus the Type 2 entry becomes relevant
Power management backoff change	The required power backoff due to power management for an activated serving cell with uplink resources has changed by more than `phr-Tx-PowerFactorChange` dB since the last PHR	`phr-ProhibitTimer` must have expired, and the UE must have UL resources for a new transmission	`P_CMAX,f,c` itself moved. Without this trigger the scheduler would keep using a ceiling that no longer exists

Table 12. PHR triggers, TS 38.321 cl. 5.4.6. Note which ones are gated by phr-ProhibitTimer and which are not -- the timer exists to stop a UE on a fading link from reporting on every grant.

⚠️

Common Pitfall

phr-Tx-PowerFactorChange = infinity disables the pathloss and power-management triggers entirely, leaving only the periodic one. That is a defensible choice on a fixed-wireless deployment and a poor one on a mobile network: a UE walking into a building can lose 20 dB in a second and the scheduler will not hear about it until phr-PeriodicTimer expires. With phr-PeriodicTimer = sf1000 that is up to a second of scheduling against a ceiling that no longer applies, and it presents as a burst of uplink HARQ failures with no obvious cause.

13. Worked Arithmetic

13.1 Encoding a buffer occupancy, and decoding it back

🧮

Worked Calculation

The UE has 3 200 octets queued on LCG 1 after building the current MAC PDU, and only LCG 1 has data.

Encode, 5-bit table (Short BSR). Find the smallest level whose upper bound is >= 3 200:

level 18: upper bound 2 806 -> too small

level 19: upper bound 3 909 -> this one

Short BSR octet: LCG ID = 1 = 001, Buffer Size = 19 = 10011

-> 0011 0011 = 0x33

Decode. The gNB reads level 19 and learns: 2 806 < BS <= 3 909. Uncertainty 1 103 octets, or 34% of the true value. A scheduler that grants for the upper bound over-grants by up to 709 octets; one that grants for the lower bound under-grants by up to 394.

Encode, 8-bit table (Long BSR). With ratio r ~ 1.065 and level 1 = 10:

10 x 1.065^(n−1) >= 3 200 -> 1.065^(n−1) >= 320

n − 1 >= ln(320) / ln(1.065) = 5.768 / 0.0630 = 91.6 -> n ~ 93

level 93 spans roughly 3 080 < BS <= 3 280 octets, a width of ~200

Uncertainty ~6% instead of 34% -- five and a half times better, for two extra octets on the wire: a Long BSR reporting one group is 2 octets of subheader + 1 bitmap + 1 size = 4, against the Short BSR's 1 + 1 = 2.

That comparison is the whole argument for Long BSRs on bulk bearers. It also shows why the choice is not free: on a 56-octet grant, three extra octets is 5% of the transport block, and the companion 09 LCP document shows who pays for it.

13.2 Power headroom from first principles

🧮

Worked Calculation

A UE is granted 20 PRB of PUSCH at 30 kHz (mu = 1). Its parameters:

P_CMAX,f,c ......... 23 dBm

P_O_PUSCH .......... −90 dBm

alpha .............. 0.8

PL ................. 105 dB

DELTA_TF ........... 0 dB (QPSK, low spectral efficiency)

f (closed loop) .... +2 dB

Bandwidth term: 10 log10(2^1 x 20) = 10 log10(40) = 16.0 dB

Required PUSCH power

= −90 + 16.0 + (0.8 x 105) + 0 + 2

= −90 + 16.0 + 84.0 + 2

= 12.0 dBm

PH_type1 = 23 − 12 = +11 dB

The scheduler now knows it has 11 dB to spend. 11 dB of bandwidth is a factor of 10^1.1 = 12.6, so it could grant up to about 250 PRB before this UE clips -- if the channel bandwidth allowed it. It could instead spend the headroom on a higher MCS, which raises DELTA_TF.

🧮

Worked Calculation

Same UE, now 125 dB of pathloss instead of 105 dB -- the user walked indoors.

Required PUSCH power = −90 + 16.0 + (0.8 x 125) + 0 + 2 = −90 + 16 + 100 + 2 = 28.0 dBm

But P_CMAX,f,c is 23 dBm, so the UE transmits at 23 dBm and reports

PH_type1 = 23 − 28 = −5 dB

The transmission went out 5 dB short of its target. The correct fix is fewer PRBs, not more power. Halving the allocation removes 3 dB:

20 PRB -> 16.0 dB bandwidth term -> PH = −5 dB

10 PRB -> 13.0 dB -> PH = −2 dB

5 PRB -> 10.0 dB -> PH = +1 dB -> feasible

So the scheduler should drop this UE to about 5 PRB. Retransmitting the same 20-PRB block, at the same power, will fail identically -- which is the signature to look for: HARQ retransmissions that never converge, with a negative PHR in the same window.

13.3 An SR-to-grant latency budget

Figure 8. The two terms of the budget. Only the first depends on configuration, and it dominates everything above about 5 ms of SR periodicity.

🧮

Worked Calculation

30 kHz SCS, so one slot = 0.5 ms. SR resource periodicityAndOffset = sl20, i.e. an occasion every 20 slots = 10 ms. Data arrives at t = 0 with no grant.

wait for the next SR occasion ....... 0 .. 10 ms, average 5.0 ms

gNB decodes PUCCH and decides ....... 2 slots = 1.0 ms

DCI to PUSCH, k2 = 4 ................ 4 slots = 2.0 ms

-----------------------------

data arrival -> first PUSCH ......... average 8.0 ms, worst 13.0 ms

That first PUSCH is the 56-octet grant that carries the BSR. Then:

gNB processes the BSR and decides .... 2 slots = 1.0 ms

DCI to PUSCH, k2 = 4 ................. 4 slots = 2.0 ms

----------------------------

data arrival -> properly sized grant . average 11.0 ms

Where to spend effort. Dropping the SR period from sl20 to sl2 (1 ms) takes the average from 8.0 ms to 3.5 ms. Going further to sym2 takes it to 3.04 ms -- the remaining 3 ms is gNB processing and k2, which no SR configuration can touch. A configured grant removes the SR and the BSR round trip entirely and gets the first data out in about 0.5 ms.

💡

Key Point

Notice which term dominates and which does not. Below about 2 ms of SR periodicity, tightening it further buys almost nothing, because the fixed 3 ms of processing and k2 takes over. Above about 10 ms, SR periodicity is the only thing that matters. Any latency-tuning exercise that does not start by reading periodicityAndOffset is starting in the wrong place.

14. How the Three Mechanisms Work Together

In steady state the three loops run at three different rates, and that separation is deliberate.

Loop	Runs at	Refreshed by	What goes wrong when it is too slow
SR	Only when the UE has no grant at all	The next SR occasion	Access latency. The UE has data and cannot say so
BSR	Every `periodicBSR-Timer`, plus every Regular trigger, plus every padding opportunity	Grants, which is why `retxBSR-Timer` exists as a backstop	Grant sizing. Buffers drain slowly or transport blocks go out padded
PHR	Every `phr-PeriodicTimer`, plus pathloss and power-management changes	The triggers in §12	Link adaptation. The scheduler picks an MCS or PRB count the UE cannot transmit, and uplink HARQ fails on a link that is actually fine

Table 13. The three loops and their timescales. SR is event-driven, BSR is fast-periodic, PHR is slow-periodic -- matching how quickly each quantity actually changes.

Once the UE has a grant, the SR loop goes quiet entirely: a UE with a continuous stream of grants never sends an SR, because every Regular BSR has somewhere to travel. That is why SR statistics are a good proxy for bursty traffic and a poor proxy for load, and why a sudden rise in SR count on a cell usually means the scheduler stopped granting speculatively rather than that traffic increased.

🔍

What You See In Logs

The most useful cross-check between the three: a BSR that keeps reporting a non-zero buffer while grants keep arriving, together with a negative PHR, is not a BSR problem. It is a PHR problem presenting as a BSR symptom -- the grants are the wrong shape, the transport blocks are failing, RLC is retransmitting, and the buffer legitimately is not draining. Chasing the BSR configuration there will waste a day.

15. Configuration Reference (ASN.1 and Ranges)

BSR-Config ::= SEQUENCE {
    periodicBSR-Timer      ENUMERATED {sf1, sf5, sf10, sf16, sf20, sf32,
                              sf40, sf64, sf80, sf128, sf160, sf320,
                              sf640, sf1280, sf2560, infinity},
    retxBSR-Timer          ENUMERATED {sf10, sf20, sf40, sf80, sf160,
                              sf320, sf640, sf1280, sf2560, sf5120,
                              sf10240, spare5, ..., spare1},
    logicalChannelSR-DelayTimer ENUMERATED {sf20, sf40, sf64, sf128,
                              sf512, sf1024, sf2560}       OPTIONAL,
    ...
}

PHR-Config ::= SEQUENCE {
    phr-PeriodicTimer         ENUMERATED {sf10, sf20, sf50, sf100, sf200,
                                 sf500, sf1000, infinity},
    phr-ProhibitTimer         ENUMERATED {sf0, sf10, sf20, sf50, sf100,
                                 sf200, sf500, sf1000},
    phr-Tx-PowerFactorChange  ENUMERATED {dB1, dB3, dB6, infinity},
    multiplePHR               BOOLEAN,
    dummy                     BOOLEAN,
    phr-Type2OtherCell        BOOLEAN,
    phr-ModeOtherCG           ENUMERATED {real, virtual},
    ...
}

SchedulingRequestConfig ::= SEQUENCE {
    schedulingRequestToAddModList
        SEQUENCE (SIZE (1..maxNrofSR-ConfigPerCellGroup))
            OF SchedulingRequestToAddMod                   OPTIONAL,
    schedulingRequestToReleaseList
        SEQUENCE (SIZE (1..maxNrofSR-ConfigPerCellGroup))
            OF SchedulingRequestId                         OPTIONAL
}

SchedulingRequestToAddMod ::= SEQUENCE {
    schedulingRequestId    SchedulingRequestId,      -- INTEGER (0..7)
    sr-ProhibitTimer       ENUMERATED {ms1, ms2, ms4, ms8, ms16, ms32,
                              ms64, ms128}           OPTIONAL,
    sr-TransMax            ENUMERATED {n4, n8, n16, n32, n64}
}

SchedulingRequestResourceConfig ::= SEQUENCE {
    schedulingRequestResourceId  SchedulingRequestResourceId,
    schedulingRequestID          SchedulingRequestId,
    periodicityAndOffset         CHOICE {
        sym2      NULL,
        sym6or7   NULL,
        sl1       NULL,
        sl2       INTEGER (0..1),
        sl4       INTEGER (0..3),
        sl5       INTEGER (0..4),
        sl8       INTEGER (0..7),
        sl10      INTEGER (0..9),
        sl16      INTEGER (0..15),
        sl20      INTEGER (0..19),
        sl40      INTEGER (0..39),
        sl80      INTEGER (0..79),
        sl160     INTEGER (0..159),
        sl320     INTEGER (0..319),
        sl640     INTEGER (0..639)
    }                                                OPTIONAL,
    resource                     PUCCH-ResourceId    OPTIONAL,
    ...
}

Listing 1. Abridged from TS 38.331. ... marks omitted members and extension markers. maxNrofSR-ConfigPerCellGroup is 8 and maxNrofSR-Resources is 64. dummy in PHR-Config is a genuine field name -- it held an EN-DC parameter that was removed before the Rel-15 freeze.

Parameter	Where	Range	Typical	Effect
logicalChannelGroup	LogicalChannelConfig	0 – 7	0 – 3	Which LCG a channel's data is reported under. The most impactful and least-tuned BSR parameter (§4)
multiplePHR	PHR-Config	BOOLEAN	true with CA	Chooses between the Single Entry PHR (LCID 57) and the Multiple Entry forms (LCID 54/56)
phr-Type2OtherCell	PHR-Config	BOOLEAN	false	Adds a Type 2 entry for the other cell group's SpCell. Only meaningful in EN-DC or NR-DC
phr-ModeOtherCG	PHR-Config	real / virtual	virtual	Whether the entry for the other cell group is a real or a virtual report
phr-Tx-PowerFactorChange	PHR-Config	dB1, dB3, dB6, infinity	dB3	How much pathloss or backoff change is needed to trigger a report (§12)
periodicityAndOffset	SchedulingRequestResourceConfig	sym2 .. sl640	sl10 – sl20	SR occasion spacing, in slots. Dominates uplink access latency (§13.3)
sr-TransMax	SchedulingRequestToAddMod	n4 .. n64	n8 – n16	How long the UE persists before releasing PUCCH and doing RACH (§3)
schedulingRequestID-BFR-SCell	MAC-CellGroupConfig	SchedulingRequestId	absent	Rel-16. A dedicated SR configuration for SCell beam failure recovery
schedulingRequestID-LBT-SCell	MAC-CellGroupConfig	SchedulingRequestId	absent	Rel-16 NR-U. A dedicated SR configuration for LBT failure reporting

Table 14. Configuration that changes what these reports look like and how often they arrive.

16. Timers and Counters

Name	Kind	Range	Typical	What happens at expiry / maximum
periodicBSR-Timer	Timer	sf1 .. sf2560, infinity	sf10 – sf20	A Periodic BSR is triggered
retxBSR-Timer	Timer	sf10 .. sf10240	sf80 – sf320	A Regular BSR is triggered if any LCG has data -- the deadlock detector (§8)
logicalChannelSR-DelayTimer	Timer	sf20, sf40, sf64, sf128, sf512, sf1024, sf2560	absent	The held-back SR becomes eligible for transmission
sr-ProhibitTimer	Timer	ms1 .. ms128	absent – ms8	The next SR occasion may be used
SR_COUNTER	Counter	0 .. `sr-TransMax`	--	At `sr-TransMax`: PUCCH, SRS, configured grants and SP-CSI released; Random Access initiated on the SpCell
sr-TransMax	Constant	n4, n8, n16, n32, n64	n8 – n16	The ceiling `SR_COUNTER` is tested against
phr-PeriodicTimer	Timer	sf10, sf20, sf50, sf100, sf200, sf500, sf1000, infinity	sf200 – sf500	A PHR is triggered
phr-ProhibitTimer	Timer	sf0, sf10, sf20, sf50, sf100, sf200, sf500, sf1000	sf10 – sf100	The pathloss-change and power-management triggers become eligible again
bitRateQueryProhibitTimer	Timer	s0, s0dot4, s0dot8, s1dot6, s3, s6, s12, s30	absent	A Recommended Bit Rate Query MAC CE may be sent again on that logical channel
timeAlignmentTimer	Timer	ms500 .. ms10240, infinity	ms1920	Uplink is unusable: all HARQ buffers flushed, SRS and PUCCH released, configured grants cleared. Every mechanism in this document stops until Random Access restores timing

Table 15. Timers and counters. sf units are subframes = milliseconds and are numerology-independent; SR periodicityAndOffset is in slots and is not.

17. Failure Modes and What Each One Means

Failure	Detected by	What the UE does	Diagnostic pointer
SR sent, no grant ever arrives	UE MAC, via `SR_COUNTER`	Retries up to `sr-TransMax`, then releases PUCCH/SRS/configured grants and starts Random Access	A RACH with a C-RNTI MAC CE and no handover and no RLF. Look backwards for the SR run -- typically 100-200 ms earlier (§3)
A logical channel has no `schedulingRequestID`	Nobody -- it is a configuration choice	Every time that channel has data and no grant, the UE goes straight to Random Access	Repeated RACH from a UE in good coverage with no mobility. Check `schedulingRequestID` on each `LogicalChannelConfig`
`sr-ProhibitTimer` longer than the SR period	Nobody	Silently skips SR occasions	The measured interval between SR transmissions is a multiple of the SR period, not the period itself. Not a fault, but it doubles or triples the effective retry interval
Chronic BSR truncation	Nobody -- truncated formats are legal	Reports fewer groups than it has	Short/Long Truncated BSRs on most PDUs. Grants are consistently too tight for the number of active LCGs, or too many LCGs are in use for the grant sizes in this cell
Buffer Size saturated at the top codepoint	Nobody	Reports index 31 (5-bit) or 255 (8-bit) for the whole burst	A scheduler that ramps on changes in reported buffer size goes flat. Switch the bearer to an LCG reported by Long BSR (§6.2)
Two dissimilar channels in one LCG	Nobody	Reports their sum as one number	Grants of the right total size and the wrong shape; delay-sensitive traffic in that group misses its budget while the group's throughput looks fine (§4)
`retxBSR-Timer` too long, and a BSR is lost	Nobody until the timer expires	Waits the whole timer before asking again	A bearer that stalls for hundreds of milliseconds to seconds with no error anywhere. Check `retxBSR-Timer` against `sf2560` (§8)
`periodicBSR-Timer` = `infinity`	Nobody	Sends BSRs only on Regular triggers and in padding	Low-priority LCG buffer estimates that go stale for long periods, worst when the cell is busy and padding is scarce
PHR reports a negative headroom and the scheduler does not react	The gNB, if it looks	Transmits at `P_CMAX`, short of target	Uplink HARQ retransmissions that never converge on a link with otherwise reasonable SINR. Reduce PRBs, not power (§13.2)
A virtual PHR read as a real one	Nobody	Nothing -- the UE reported correctly	The scheduler over-allocates a newly activated carrier because a 1-PRB reference calculation looked like 25 dB of spare capacity (§10)
`phr-Tx-PowerFactorChange` = `infinity` on a mobile UE	Nobody	Reports only on `phr-PeriodicTimer`	Bursts of uplink HARQ failure correlated with UE movement and cleared by the next periodic PHR (§12)
`timeAlignmentTimer` expiry	UE MAC	Stops all uplink: HARQ buffers flushed, PUCCH and SRS released, configured grants cleared, and Random Access is required before anything can be reported again	All three mechanisms in this document go silent at once. See the companion 04 Timing Advance document

Table 16. Failure modes across all three mechanisms. The recurring pattern: almost none of these produce an error anywhere, and most present as a symptom in a different subsystem than the one at fault.

💡

Key Point

Three signatures worth memorising. RACH with a C-RNTI CE, no handover, no RLF = an SR that was never answered. Truncated BSRs on most PDUs = grants too small for the number of active LCGs. Uplink HARQ that never converges with a negative PHR in the window = over-allocation, not coverage. Each of those takes one grep to confirm and each is routinely misdiagnosed as a radio problem.

18. Illustrative Message Traces

🔍

About These Traces

Illustrative trace. Field names and encodings follow 3GPP; the values are constructed for this document and are not a capture from any deployed or lab network.

18.1 The configuration all three mechanisms run from

[RRC-DL] bsr-Config, phr-Config, schedulingRequestConfig

RRCReconfiguration
 cellGroupConfig
  mac-CellGroupConfig
   bsr-Config
    periodicBSR-Timer ................ sf20      -- 20 ms
    retxBSR-Timer .................... sf80      -- 80 ms
    logicalChannelSR-DelayTimer ...... (absent)
   phr-Config: setup
    phr-PeriodicTimer ................ sf500     -- 500 ms
    phr-ProhibitTimer ................ sf20      -- 20 ms
    phr-Tx-PowerFactorChange ......... dB3
    multiplePHR ...................... TRUE      -- CA is configured
    dummy ............................ FALSE
    phr-Type2OtherCell ............... FALSE     -- no NR-DC
    phr-ModeOtherCG .................. virtual
   schedulingRequestConfig
    schedulingRequestToAddModList
     [0] schedulingRequestId ......... 0
         sr-ProhibitTimer ............ ms16
         sr-TransMax ................. n8
  spCellConfig
   spCellConfigDedicated
    uplinkConfig
     initialUplinkBWP
      pucch-Config: setup
       schedulingRequestResourceToAddModList
        [0] schedulingRequestResourceId 1
            schedulingRequestID ....... 0
            periodicityAndOffset
             sl20 .................... 3      -- every 20 slots, offset 3
                                              -- = every 10 ms at 30 kHz
            resource .................. 0      -- PUCCH format 0, 1 symbol
  rlc-BearerToAddModList
   [0] logicalChannelIdentity 1  ul-SpecificParameters
        priority 1   logicalChannelGroup 0   schedulingRequestID 0
   [1] logicalChannelIdentity 5  ul-SpecificParameters
        priority 4   logicalChannelGroup 1   schedulingRequestID 0
   [2] logicalChannelIdentity 6  ul-SpecificParameters
        priority 6   logicalChannelGroup 2   schedulingRequestID 0
   [3] logicalChannelIdentity 7  ul-SpecificParameters
        priority 9   logicalChannelGroup 2   schedulingRequestID 0

Listing 2. The configuration used in every trace below. Note LCID 6 and LCID 7 sharing LCG 2 -- the grouping mistake discussed in §4, left in place here so its effect is visible in §18.4.

18.2 The happy path: SR, BSR, PHR, grant, data

[MAC-UL] SR -> BSR + PHR -> grant -> data

11:52:04.0000  [MAC] UL data available: LCID 5 (LCG 1), 620 octets
                     no LCG had data before this -> Regular BSR triggered
                     no UL grant available        -> SR triggered, SR id 0
                     SR_COUNTER = 0

11:52:04.0035  [MAC-UL] SR occasion (sl20 offset 3, slot 7815.3)
                        SR transmitted on PUCCH resource 0, format 0
                        SR_COUNTER = 1, sr-ProhibitTimer ms16 started
                        -- 3.5 ms elapsed since the trigger: pure periodicity

11:52:04.0045  [MAC-DL] DCI 0_1, C-RNTI 0x6B12: UL grant, TBS 56 octets
                        k2 = 4 -> PUSCH in slot 7815.8
11:52:04.0045  [MAC]    retxBSR-Timer sf80 started (grant for new data)

11:52:04.0065  [MAC-UL] PUSCH, 56 octets, HARQ pid 3
  subPDU 1  R=0 F=0 LCID=5   L=47      47 octets of DTCH  (SDUs first, UL)
  subPDU 2  R=0 F=0 LCID=62  L=2       Long BSR -- variable size, so it
                                       carries an L field
            bitmap ................... 0000 0010   -- LCG 1 only
            Buffer Size LCG 1 ........ 66          -- 8-bit level, approx.
                                                      565 .. 600 octets
  subPDU 3  R=0 R=0 LCID=57            Single Entry PHR -- fixed size, so
                                       no L field
            PH ....................... 44          -- approx. +11 dB
            P_CMAX,f,c ............... 52          -- approx. 23 dBm
  accounting: (2+47) + (2+2) + (1+2) = 49 + 4 + 3 = 56 = TBS  [consistent]

11:52:04.0065  [MAC]    BSR transmitted:
                        - all triggered BSRs cancelled
                        - pending SR cancelled, SR_COUNTER reset to 0
                        - periodicBSR-Timer sf20 restarted
11:52:04.0065  [MAC]    PHR transmitted: phr-PeriodicTimer sf500 restarted,
                        phr-ProhibitTimer sf20 started

11:52:04.0085  [MAC-DL] DCI 0_1: UL grant, TBS 640 octets
                        -- sized from Buffer Size 66, whose upper bound is
                        -- 600 octets; PRB count and MCS bounded by PH 44
11:52:04.0105  [MAC-UL] PUSCH, 640 octets, HARQ pid 5
  subPDU 1  R=0 F=1 LCID=5   L=573     the remaining LCID 5 data
                                       (573 > 255, so a 16-bit L field)
  subPDU 2  R=0 R=0 LCID=61            Short BSR, LCG 1, index 0 -- EMPTY
  subPDU 3  R=0 R=0 LCID=63            Padding subheader + 61 octets
  accounting: (3+573) + (1+1) + (1+61) = 576 + 2 + 62 = 640 = TBS  [ok]

11:52:04.0105  [MAC]    Buffer Size 0 reported -> end-of-burst marker.
                        Scheduler should stop granting after this.

Listing 3. The complete SR-BSR-PHR-grant-data sequence. Total from data arrival to the properly sized grant: 8.5 ms, of which 3.5 ms was SR periodicity. Note the subheader shapes: the Long BSR needs an L field and the Single Entry PHR does not.

🔍

What You See In Logs

Two things in that trace are worth pointing at. The Buffer Size 0 in the last PDU is the end-of-burst marker -- it is the only way the network learns the UE is finished, and a scheduler that keeps granting after it is wasting resource on padding. And the 62 octets of padding are the price of quantisation: the 8-bit level the UE reported bounds the buffer at 600 octets when it actually held 573, the scheduler rounded up to the next transport block size, and the slack went out as padding. That is 10% of the grant, on the fine table.

18.3 A failure: sr-TransMax exhaustion

[MAC-UL] sr-TransMax reached

12:03:11.2000  [MAC] UL data available: LCID 5 (LCG 1), 340 octets
                     Regular BSR triggered, no grant -> SR triggered

12:03:11.2035  [MAC-UL] SR #1  SR_COUNTER = 1   sr-ProhibitTimer ms16 started
12:03:11.2135  [MAC]    SR occasion at 10 ms SKIPPED -- sr-ProhibitTimer running
12:03:11.2235  [MAC-UL] SR #2  SR_COUNTER = 2   (20 ms after #1, not 10)
12:03:11.2435  [MAC-UL] SR #3  SR_COUNTER = 3
12:03:11.2635  [MAC-UL] SR #4  SR_COUNTER = 4
12:03:11.2835  [MAC-UL] SR #5  SR_COUNTER = 5
12:03:11.3035  [MAC-UL] SR #6  SR_COUNTER = 6
12:03:11.3235  [MAC-UL] SR #7  SR_COUNTER = 7
12:03:11.3435  [MAC-UL] SR #8  SR_COUNTER = 8 = sr-TransMax (n8)
                        -- 143 ms elapsed since the trigger
12:03:11.3635  [MAC]    SR occasion, SR_COUNTER = sr-TransMax:
                        -> notify RRC: release PUCCH, all serving cells
                        -> release SRS, all serving cells
                        -> clear all configured DL assignments and UL grants
                        -> clear SP-CSI PUSCH resources
                        -> cancel all pending SRs
                        -> initiate Random Access on the SpCell

12:03:11.3660  [MAC-UL] MSG1: preamble 41, RA-RNTI 1204
12:03:11.3720  [MAC-DL] MSG2: RAR, TA cmd 61, TC-RNTI 0x6B12 grant
12:03:11.3760  [MAC-UL] MSG3: C-RNTI MAC CE (UL LCID 58), C-RNTI 0x6B12
                        -- the UE already has an identity, so the CE IS the
                        -- contention resolution; no 48-bit echo is needed
12:03:11.3820  [MAC-DL] PDCCH to C-RNTI 0x6B12 -> RA successful
12:03:11.3860  [MAC-UL] PUSCH: Long BSR (LCG 1 idx 132) + 40 octets

-- Diagnosis: 143 ms of SR attempts, then a full uplink control teardown and
-- a RACH, to deliver 340 octets. Nothing was wrong with the radio: the
-- PUCCH SR was being received or not, but no grant followed. Look at the
-- scheduler, not the link. Note also that sr-ProhibitTimer ms16 against a
-- 10 ms SR period doubled the retry interval to 20 ms.

Listing 4. SR exhaustion and the RACH that follows. The C-RNTI MAC CE in MSG3 is the marker that distinguishes this from an initial access.

18.4 BSR truncation, and what LCG grouping costs

[MAC-UL] Long Truncated BSR

12:18:47.5000  [MAC-UL] grant: TBS 40 octets, C-RNTI 0x6B12
12:18:47.5000  [MAC] buffers: LCG 0 =    0 octets
                              LCG 1 =  310 octets  (LCID 5, voice, prio 4)
                              LCG 2 = 48200 octets (LCID 6 video prio 6 +
                                                    LCID 7 bulk  prio 9)
12:18:47.5000  [MAC] Regular BSR pending (retxBSR-Timer expired)

12:18:47.5000  [MAC] format selection:
   more than one LCG has data                        -> not a Short BSR
   full Long BSR = 2 subhdr + 1 bitmap + 2 sizes = 5 octets
   room available after data selection = 4 octets    -> full Long BSR
                                                        does NOT fit
   room for bitmap + 1 size field = 4 octets         -> LONG TRUNCATED BSR

12:18:47.5020  [MAC-UL] PUSCH, 40 octets, HARQ pid 1
  subPDU 1  LCID 5   L=34                34 octets of voice
  subPDU 2  LCID 60  L=2                 Long Truncated BSR
            bitmap ................... 0000 0110   -- LCG 1 AND LCG 2 have data
            Buffer Size LCG 1 ........ 54           -- approx. 265 .. 282 octets
            -- LCG 2's size is OMITTED. The bitmap still declares it active.
  accounting: 36 + 4 = 40 octets = TBS                   [consistent]

12:18:47.5040  [MAC-DL] DCI 0_1: UL grant, TBS 309 octets
                        -- gNB granted for LCG 1 (276 octets) plus a margin
                        -- for the unreported LCG 2. It has no idea LCG 2
                        -- holds 48 kB.
12:18:47.5060  [MAC-UL] PUSCH, 309 octets
  subPDU 1  LCID 5   L=276              voice, now empty
  subPDU 2  LCID 6   L=25               25 octets of a 48 kB backlog
  subPDU 3  LCID 62  L=2                Long BSR
            bitmap ................... 0000 0100   -- LCG 2 only now
            Buffer Size LCG 2 ........ 136          -- approx. 46 300 .. 49 300
                                                       octets. Full report at last.

-- Two costs are visible. (1) The truncated report cost one extra round trip
-- before the scheduler learned the real backlog. (2) LCG 2 lumps video and
-- bulk together, so even the full report cannot tell the scheduler that
-- 2 kB of that 48 kB is delay-sensitive video and the rest is not.

Listing 5. A Long Truncated BSR on a 40-octet grant, and the extra round trip it costs. The bitmap is the part that still carries useful information.

18.5 A power-limited UE

[MAC-UL] Multiple Entry PHR with a power-limited PCell

12:31:02.8000  [MAC-UL] PUSCH: 20 PRB, MCS 9, HARQ pid 4
12:31:02.8000  [PHY]    P_PUSCH computed 28.0 dBm, clipped to P_CMAX 23.0 dBm
12:31:02.8060  [MAC-DL] HARQ pid 4: NACK
12:31:02.8100  [MAC-UL] PUSCH: 20 PRB, MCS 9, HARQ pid 4, rv 1  (retx)
12:31:02.8160  [MAC-DL] HARQ pid 4: NACK
12:31:02.8200  [MAC-UL] PUSCH: 20 PRB, MCS 9, HARQ pid 4, rv 2  (retx)
12:31:02.8260  [MAC-DL] HARQ pid 4: NACK

12:31:02.8300  [MAC] pathloss changed by 20 dB since the last PHR (105 -> 125)
                     phr-Tx-PowerFactorChange = dB3, phr-ProhibitTimer expired
                     -> PHR triggered
12:31:02.8320  [MAC-UL] PUSCH, 88 octets, HARQ pid 6
  subPDU 1  LCID 5   L=77              (2 + 77 = 79 octets)
  subPDU 2  LCID 54  L=7               Multiple Entry PHR, 4-octet Ci bitmap
            Ci bitmap ................ C1 = 1, all others 0
            entry: PCell   P=0 V=0  PH = 22   -- approx. -5 dB, REAL, Type 1
                           P_CMAX,f,c = 52    -- approx. 23 dBm
            entry: SCell 1 P=0 V=1  PH = 58   -- approx. +25 dB, VIRTUAL
                           -- no P_CMAX octet: computed for a 1-PRB reference
  accounting: 79 + 9 = 88 octets = TBS                    [consistent]
                       -- ME PHR payload = 4 bitmap + 2 (PCell, V=0)
                       --                + 1 (SCell 1, V=1) = 7 octets

12:31:02.8380  [MAC-DL] DCI 0_1: UL grant, 5 PRB, MCS 4
                        -- scheduler removed 6 dB of bandwidth term:
                        -- 10log10(2 x 20) = 16.0 dB  ->  10log10(2 x 5) = 10.0 dB
12:31:02.8400  [MAC-UL] PUSCH: 5 PRB, MCS 4, HARQ pid 7
12:31:02.8400  [PHY]    P_PUSCH computed 22.0 dBm, within P_CMAX 23.0 dBm
12:31:02.8460  [MAC-DL] HARQ pid 7: ACK

-- The three failed HARQ attempts before the PHR were unwinnable: the block
-- was 5 dB short of its target on every rv. The PHR is what fixed it, and
-- phr-ProhibitTimer is what delayed it. A shorter prohibit timer would have
-- cost one report and saved three retransmissions.
-- Note the SCell 1 entry: +25 dB looks like a lot of spare capacity. It was
-- computed for ONE PRB. At 50 PRB the same UE would have about 5 dB.

Listing 6. A negative Type 1 headroom, the retransmissions it caused, and the scheduler's correct response. The virtual SCell entry in the same CE is the trap described in §10.

19. Release Deltas: Rel-15 to Rel-18

Release	Change	Why it matters when reading these reports
Rel-15	SR with `sr-ProhibitTimer` / `sr-TransMax`; the four BSR formats and both quantisation tables; Single and Multiple Entry PHR with Type 1 and Type 2	Everything in §2 through §12 except where noted. This is the baseline and it covers the great majority of real traffic
Rel-16	Type 3 power headroom for SRS-only carriers	A PHR entry can now describe a carrier the UE never sends data on. Check the entry type before comparing headroom figures
Rel-16	`schedulingRequestID-BFR-SCell`: a dedicated SR configuration for SCell beam failure recovery	An SR that is not about data at all. Its `SR_COUNTER` is separate, so it can exhaust independently
Rel-16	`schedulingRequestID-LBT-SCell`: a dedicated SR configuration for consistent LBT failure (NR-U)	As above, for channel-access failures on unlicensed carriers
Rel-16	Pre-emptive BSR for IAB (`usePreBSR`): an IAB-MT reports data it expects to receive from a child node	A BSR that describes data which has not arrived. It also carries the only exception to the uplink CE ordering rule -- see the companion 07 MAC PDU and Control Elements document
Rel-16	Sidelink BSR and Truncated Sidelink BSR (UL LCID 45/46)	A second, parallel BSR mechanism. Make sure the report you are reading is the uplink one
Rel-16	Intra-UE prioritisation: an SR can be dropped in favour of an overlapping PUSCH, and vice versa	An SR occasion can be skipped for a reason other than `sr-ProhibitTimer`, and nothing logs it as a failure
Rel-17	Enhanced BFR reporting per TRP; further IAB reports in the CE priority list	More control elements competing for the same small grants that BSRs and PHRs travel in
Rel-17	NTN: very long propagation delays change what an SR-to-grant budget looks like	The 3 ms of fixed processing and k2 in §13.3 becomes tens or hundreds of milliseconds
Rel-18	Refinements for XR and low-latency traffic, including discard-timer-aware buffer reporting proposals and further multi-PUSCH scheduling	The formats and the quantisation tables are unchanged. What changes is how often a report can be sent and how many grants one DCI produces

Table 17. BSR, PHR and SR changes by release. The wire formats of all four BSRs and both PHRs are unchanged since Rel-15; the additions are new triggers, new SR configurations, and Type 3 headroom.

🔄

Release Delta

Neither buffer size table has changed since Rel-15, which is why the 150 000-octet ceiling on the 5-bit table has become more of a problem over time rather than less: uplink rates have risen by an order of magnitude and the Short BSR still saturates at 150 kB. On a bearer that can exceed that in a few milliseconds, the Short BSR is a binary "lots" indicator and nothing more.

20. Reading BSR, PHR and SR in Logs: a Checklist

1. Convert `periodicityAndOffset` to milliseconds before anything else. It is in slots, so its meaning depends on the numerology. sl20 is 20 ms at 15 kHz and 2.5 ms at 120 kHz, and this term usually dominates the uplink latency budget (§13.3).

2. Measure the actual interval between SR transmissions, not the configured period. sr-ProhibitTimer causes occasions to be skipped, so the effective retry interval is the prohibit time rounded up to the next occasion (§3).

3. On any RACH, look for the C-RNTI MAC CE. Its presence means the UE already had an identity, so this was not an initial access. Combined with no handover and no RLF, it points at sr-TransMax exhaustion 100-200 ms earlier.

4. Read the BSR LCID, not just the buffer size. LCID 59 and 60 are truncated -- the report is incomplete by design. A truncated BSR on most PDUs is a grant-sizing finding, not a UE fault (§5).

5. Translate every Buffer Size index into a range, never a number. The 5-bit table carries about 28% uncertainty at every scale, and index 31 means only "more than 150 kB" (§6).

6. Watch for the buffer size 0 report. It is the end-of-burst marker and the only clean signal that the UE has finished. Grants continuing after it are wasted.

7. Check `retxBSR-Timer` against the stall you are investigating. A bearer that hangs for a period suspiciously close to retxBSR-Timer and then resumes has lost a BSR (§8).

8. Read the V bit on every PHR entry before believing the number. A virtual entry was computed for a one-PRB reference format and is a pathloss indication, not spare capacity (§10).

9. Treat a negative PH as an instruction, not an alarm. It means reduce PRBs or MCS. Uplink HARQ that never converges with a negative PH in the same window is an over-allocation, not a coverage problem (§13.2).

10. Cross-check the P bit and `P_CMAX,f,c`. If P_CMAX,f,c is well below the band's nominal maximum and the P bit is set, the UE is applying power-management backoff and no scheduler change will recover the headroom.

11. Confirm the LCG assignment against the bearer priorities. Two channels of very different urgency in one group is invisible in every individual report and is the root cause of a whole class of "the throughput is fine but the latency is not" reports (§4).

21. Glossary

Term	Expansion	Meaning in this document
SR	Scheduling Request	One bit on PUCCH meaning "I want a grant". Triggered by a Regular BSR with no grant to travel on TS 38.321 cl. 5.4.4
BSR	Buffer Status Report	A MAC CE reporting quantised buffer occupancy per logical channel group TS 38.321 cl. 5.4.5
PHR	Power Headroom Report	A MAC CE reporting, in dB, the difference between `P_CMAX,f,c` and the power a transmission required TS 38.321 cl. 5.4.6
LCG	Logical Channel Group	One of at most eight groups, set by `logicalChannelGroup`. The granularity at which buffer status is reported
Buffer Size level	--	A 5-bit or 8-bit index into a geometrically spaced table. Index n means "greater than level n−1, at most level n"
Regular BSR	--	Triggered by data arriving on a higher-priority LCG, on any LCG when nothing was buffered, or by `retxBSR-Timer` expiry. Can trigger an SR
Periodic BSR	--	Triggered by `periodicBSR-Timer` expiry. Never triggers an SR
Padding BSR	--	Included when the padding remaining after building a PDU is at least 2 octets. Ranks below all data in the CE priority list, so it is free
Truncated BSR	--	Short (LCID 59) or Long (LCID 60). Declares explicitly that the report is incomplete
P_CMAX,f,c	UE configured maximum output power	The ceiling headroom is measured from, for carrier f on serving cell c. Not constant -- it varies with band, bandwidth and power management
Type 1 / 2 / 3 PH	--	Headroom for PUSCH / for PUSCH+PUCCH on the other cell group / for SRS only
Real / virtual PH	--	V = 0: measured from an actual transmission, `P_CMAX,f,c` octet present. V = 1: computed for a one-PRB reference format, `P_CMAX,f,c` octet omitted
`P` bit	--	Set when the UE applied power backoff for power-management reasons, so `P_CMAX,f,c` was below its nominal capability
SR_COUNTER	--	Per-SR-configuration count of SR transmissions. At `sr-TransMax` the UE releases its uplink control configuration and does Random Access

22. References

3GPP TS 38.321 -- NR MAC protocol specification. Clause 5.4.4 (Scheduling Request), 5.4.5 (Buffer Status Reporting -- triggers, format selection, cancellation), 5.4.6 (Power Headroom Reporting -- triggers and prohibition), 5.4.3.1.3 (where BSR and PHR sit against logical channel data), 6.1.3.1 (BSR MAC CE formats and Tables 6.1.3.1-1 and 6.1.3.1-2 for the buffer size levels), 6.1.3.8 (Single Entry PHR), 6.1.3.9 (Multiple Entry PHR), 6.2.1 and Table 6.2.1-2 (UL-SCH LCID values).
3GPP TS 38.213 -- Physical layer procedures for control. Clause 7.1 (PUCCH power control), clause 7.7 (power headroom definitions for Type 1, Type 2 and Type 3, and the reference formats used for virtual reports), clause 9.2.5 (SR on PUCCH and its multiplexing with other uplink control information).
3GPP TS 38.133 -- Requirements for support of radio resource management. The power headroom reporting range and the P_CMAX,f,c reporting range, with their index-to-value mappings and accuracy requirements.
3GPP TS 38.101-1 / 38.101-2 -- UE radio transmission and reception. P_CMAX definition, maximum power reduction, and the power-management allowance the P bit refers to.
3GPP TS 38.331 -- RRC protocol specification. BSR-Config, PHR-Config, SchedulingRequestConfig, SchedulingRequestToAddMod, SchedulingRequestResourceConfig, LogicalChannelConfig (logicalChannelGroup, schedulingRequestID, logicalChannelSR-Mask, logicalChannelSR-DelayTimerApplied), MAC-CellGroupConfig.
3GPP TS 38.322 -- NR RLC protocol specification. Clause 5.5 (data volume calculation -- what "data available for transmission" means for a BSR).
3GPP TS 38.323 -- NR PDCP protocol specification. Clause 5.10 (data volume calculation, the PDCP contribution to the reported buffer).
3GPP TS 38.300 -- NR overall description. Clause 10 (scheduling and the role of uplink reporting).

Companion documents in this set

03 Random Access -- the fallback when sr-TransMax is reached, and the C-RNTI MAC CE that identifies such a RACH.
04 Timing Advance -- timeAlignmentTimer, whose expiry silences all three mechanisms at once.
05 HARQ -- the retransmissions that a negative power headroom produces, and why they do not converge.
06 Channel Mapping -- logical channels, and where logicalChannelIdentity comes from.
07 MAC PDU and Control Elements -- the BSR and PHR control elements in the wider CE catalogue, the subheaders they travel under, and the padding rules that produce padding BSRs.
08 Scheduling -- what the gNB actually does with a BSR and a PHR.
09 LCP -- how these reports compete with data for room in a grant, and the fixed priority order that puts a triggered BSR above data and a padding BSR below it.
11 DRX -- why an SR occasion may fall outside an active time, and what that does to the latency budget in §13.3.
12 Beam Failure Recovery -- the Rel-16 dedicated SR configuration for SCell beam failure.