5G NR MAC Scheduling Request (SR)
Scheduling Request is the MAC mechanism used by the UE to indicate that uplink scheduling opportunity is needed. It is one of the most important first checks when uplink data appears delayed, starved, or unexpectedly idle.
This page focuses on the MAC-side interpretation of Scheduling Request. In real traces, SR is most useful when read together with Buffer Status Report, grant timing, DRX state, PUCCH context, and the actual presence of buffered traffic. Use it with the 5G NR MAC Overview page when tracing uplink demand signaling end to end.
| Technology | 5G NR |
|---|---|
| Protocol area | MAC uplink control |
| Main specification | 3GPP TS 38.321 |
| Related specifications | 3GPP TS 38.331, 3GPP TS 38.213, 3GPP TS 38.214 |
| Release baseline | Release 18 |
| Main role | Signal need for uplink scheduling opportunity |
| Best paired with | Buffer Status Report, DRX, PUCCH, grants, and uplink troubleshooting |
| Common confusion | SR indicates need for resource; it does not describe full queue size like BSR |
Definition and purpose
Scheduling Request tells the network that uplink opportunity is needed. It is not a full backlog report and should not be read as one. The practical interpretation is that the UE is asking for a chance to send uplink data or control when ordinary grant availability is not already sufficient.
When SR is absent, delayed, or misunderstood, uplink traffic may appear stalled even though data is waiting higher in the stack. That is why SR is one of the first MAC signals engineers inspect when uplink responsiveness looks wrong.
Where it fits
Buffered data appears -> SR indicates need for uplink opportunity -> scheduler grants resource -> BSR and data progression become visible- SR is often the earliest visible sign that uplink demand exists.
- Buffer Status Report gives deeper queue context after or alongside the scheduling path.
- DRX can change when SR is observed or acted upon.
- PUCCH context is often important for practical SR interpretation.
Trigger conditions
| Trigger area | Why SR becomes relevant |
|---|---|
| Buffered uplink data exists | The UE has uplink demand but no immediately usable scheduling opportunity. |
| Grant response is not already available | SR is used when existing resources are insufficient for the needed uplink progression. |
| State and configuration allow SR use | SR behavior depends on MAC and RRC configuration plus current UE state. |
| Procedure timing makes uplink demand visible | SR is interpreted meaningfully only inside the current scheduling and monitoring context. |
Why SR must be read with state and timing
SR is only useful when it is interpreted in the right state context. DRX, current monitoring state, grant history, and uplink procedure timing all affect when SR appears and how quickly it leads to a usable grant.
That is why SR should never be judged by presence alone. The useful question is whether SR showed up at the right time and whether the scheduler response matched the actual need.
SR versus BSR
| Item | Main purpose | What it does not tell you |
|---|---|---|
| SR | That uplink opportunity is needed | The full amount of queued data |
| BSR | How much backlog is waiting | Whether the scheduler was first alerted cleanly |
PUCCH and configuration context
In practical traces, SR is frequently tied to PUCCH resources and the higher-layer configuration that enables or constrains how the UE can signal uplink demand. That means SR behavior is not only a MAC topic. It is also shaped by PHY control-channel context and RRC configuration.
If SR seems missing, sparse, or mistimed, the problem may be configuration or state interpretation rather than lack of actual uplink demand.
Typical SR-related problem patterns
- Traffic is waiting but no demand signal becomes visible in the expected window.
- Demand signal is visible but the grant comes too late to keep latency acceptable.
- SR repeats but the real limiting factor turns out to be power, timing, or retransmission behavior.
- DRX state makes the apparent SR pattern look weaker than it really is.
Call-flow relevance
| Procedure area | Why SR matters |
|---|---|
| Uplink demand start | SR is often the first MAC-visible sign that uplink transmission opportunity is needed. |
| Connected-mode signaling | Delayed or missing SR can slow control-plane responsiveness when uplink resources are needed. |
| User-plane transfer | SR influences how quickly waiting uplink traffic can begin moving when grants are not already available. |
| Uplink troubleshooting | SR helps separate no-demand problems from no-opportunity problems. |
Log-analysis notes
A useful SR analysis should correlate four things: whether buffered traffic existed, whether SR was allowed and visible, whether the scheduler responded with a grant, and whether the later grant actually solved the uplink problem.
In many traces, SR is not the final root cause but the first diagnostic branch point. It tells you whether the issue begins with missing demand indication or later with grants, queue state, power limitation, retransmissions, or timing behavior. That is why SR should be read together with BSR, PHR, HARQ, and Timing Advance.
Troubleshooting
| Symptom | MAC area to inspect | Why |
|---|---|---|
| Buffered data but no visible SR | SR configuration, state gating, and DRX context | SR may be unavailable, masked, or misread in the active state rather than truly absent. |
| SR seen but no useful grant | Grant response timing and load context | The demand signal exists, but the scheduler response may still be too late or too small. |
| Repeated SR with weak progress | SR versus BSR, grant size, power, timing, or HARQ behavior | The real bottleneck may no longer be demand indication itself. |
| Intermittent uplink delay | DRX timing and SR visibility window | The apparent SR weakness may actually be state and monitoring behavior. |
| Uplink still poor after grant arrives | BSR, PHR, HARQ, and Timing Advance context | SR may have worked correctly while a later uplink limitation still prevents good progress. |
What to check when SR does not seem to help
- Check whether buffered traffic existed at the time you expected SR behavior.
- Check whether SR was configured, allowed, or masked by the current state.
- Check whether DRX, load, or control conditions delayed the grant response.
- Check whether the real issue is grant size, power limitation, timing, or HARQ behavior rather than missing demand indication.
FAQ
What is Scheduling Request in 5G NR MAC?
It is the MAC-level indication that the UE needs uplink scheduling opportunity.
How is SR different from BSR?
SR tells the network that uplink opportunity is needed, while BSR gives queue or backlog context.
Why is SR important for troubleshooting?
Because it is one of the fastest ways to separate no-demand problems from no-opportunity problems in uplink analysis.
Why can uplink still be slow even when SR is present?
Because the issue may be grant timing, DRX state, power limits, queue priority, or radio reliability rather than missing demand indication.
Is SR only a MAC topic?
No. SR is a MAC mechanism, but practical interpretation also depends on PHY control-channel context such as PUCCH and higher-layer configuration.
What should I check first if SR is missing?
Check whether data was really buffered, whether SR was configured and allowed in the current state, and whether DRX or other state conditions affected visibility.