Description
The Scheduling Request (SR) is a crucial uplink control channel procedure in 3GPP radio access networks, primarily defined for LTE and NR. It operates within the Medium Access Control (MAC) layer. When a UE has data to transmit in its uplink buffer but lacks a valid Physical Uplink Shared Channel (PUSCH) resource grant, it triggers an SR. The UE sends this request via dedicated Physical Uplink Control Channel (PUCCH) resources configured by the network through Radio Resource Control (RRC) signaling. These resources are periodic and defined by parameters like sr-ProhibitTimer and sr-ConfigIndex, which control how often a UE can attempt to send an SR to prevent overload.
The SR mechanism is designed for low latency and efficiency. Upon receiving an SR, the gNB/eNB scheduler allocates an uplink grant on the PUSCH via a Downlink Control Information (DCI) format on the Physical Downlink Control Channel (PDCCH). The UE then uses this grant to transmit a Buffer Status Report (BSR), providing detailed information about the amount and priority of data in its buffers, enabling more informed subsequent scheduling. If the SR is not successfully received (e.g., due to poor radio conditions), the UE will re-attempt after a configured period or may eventually trigger a Random Access Channel (RACH) procedure as a fallback to re-establish uplink synchronization and request resources.
SR configurations are highly flexible. They can be configured per logical channel group or per UE, supporting multiple SR configurations for different services (e.g., ultra-reliable low-latency communication (URLLC) versus enhanced mobile broadband (eMBB)). In NR, the SR is carried on PUCCH format 0 or 1, with the specific resource indicating the SR occasion. The network manages SR resources as part of the overall uplink control information (UCI), balancing the need for quick access against control channel overhead. This procedure is foundational to dynamic scheduling, a key advantage of OFDMA-based systems over fixed resource allocation.
Purpose & Motivation
The Scheduling Request was introduced to solve the problem of efficient and dynamic uplink resource allocation in packet-switched cellular systems. Prior systems like GSM/GPRS used more static or contention-based access, which was inefficient for bursty data traffic. The SR mechanism allows the network to maintain centralized control over uplink resources while responding rapidly to UE needs. It addresses the core challenge of not knowing when a UE has data to send without requiring the UE to constantly transmit, which would waste power and spectral resources.
Its creation was motivated by the need for low-latency, high-efficiency scheduling in LTE (from Rel-8 onwards) to support real-time services and internet applications. By providing a fast, dedicated signaling path for resource requests, it reduces the time and signaling overhead compared to always using the RACH procedure. It enables the network to scale scheduling decisions across many UEs efficiently, a necessity for the high-capacity, low-latency goals of 4G and 5G. The SR is a key enabler for quality of service (QoS) differentiation, as different SR configurations can be assigned based on service requirements.
What changed in its specifications
The latest release-to-release comparison of specifications that define SR. Each summary describes the whole specification, not only this term.
Rel-18 brings only minor changes to TS 21.905: 0 clauses changed, with no change attributed to a release feature.
Full comparison in TR 21.905 →Rel-19 adds a reference to the IVAS fixed-point C code specification in TS 26.114. It also lists that specification among supported specifications for MTSI immersive audio clients.
Full comparison in TS 26.114 →Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (1 CRs across 1 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Defining Specifications
3GPP specifications that define or reference SR, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 21.905 vj20 | 3GPP Terminology and Definitions | Rel-19 read |
| TR 22.804 vg30 | 5G Automation in Vertical Domains Study | Rel-16 read |
| TS 25.800 vc10 | UMTS Heterogeneous Networks Study | Rel-12 read |
| TS 26.114 vk11 | IMS Multimedia Telephony Client | Rel-20 read |
| TS 26.260 vj10 | Objective test methods for immersive audio | Rel-19 read |
| TS 26.565 vj00 | Split Rendering Media Service Enabler | Rel-19 read |
| TS 26.567 vj20 | IMS-Based Split Rendering | Rel-19 read |
| TS 29.549 vk10 | SEAL Service APIs | Rel-20 read |
| TS 29.892 vg00 | Study on User Plane Protocol in 5GC | Rel-16 read |
| TR 33.916 vk00 | Security Assurance Methodology (SECAM) Evaluation Process | Rel-20 read |
| TS 36.212 vj30 | E-UTRA Physical Layer Procedures | Rel-19 read |
| TS 36.213 vj50 | LTE Physical Layer Procedures | Rel-19 read |
| TS 36.300 vj20 | E-UTRAN Radio Interface Protocol Architecture | Rel-19 read |
| TS 36.306 vj30 | E-UTRA UE Radio Access Capability Parameters | Rel-19 read |
| TS 36.321 vj30 | E-UTRA MAC Protocol Specification | Rel-19 read |
| TS 36.331 vj40 | E-UTRA Radio Resource Control (RRC) Protocol | Rel-19 read |
| TS 36.822 vb00 | LTE RAN Enhancements for Diverse Data Apps | Rel-11 read |
| TS 37.870 vd00 | Study on Multi-RAT Joint Coordination | Rel-13 read |
| TS 38.212 vj40 | NR Multiplexing and Channel Coding | Rel-19 read |
| TS 38.213 vj50 | NR Physical Layer Control Procedures | Rel-19 read |
| TS 38.214 vj50 | NR Physical Layer Data Channel Procedures | Rel-19 read |
| TS 38.300 vj40 | NR and NG-RAN Overall Description | Rel-19 read |
| TS 38.321 vj40 | NR MAC Protocol Specification | Rel-19 read |
| TR 38.825 vg00 | Study on NR Industrial IoT | Rel-16 read |
| TR 38.830 vh00 | NR Coverage Enhancements Study | Rel-17 read |
| TR 38.838 vh00 | Study on XR Evaluations for NR | Rel-17 read |