The concept of Scheduling request is same for LTE and 5G NR. Scheduling request is way for UE to tell the network that it has some data in its MAC buffer and it needs PHY resources in Uplink to send that data. Scheduling Request (SR) is only triggered when the UE does not any have any uplink resources scheduled to transmit any data i.e PUSCH resources
From a Network stand point view the network can periodically allocate UL resources via PUSCH to UE, incase if UE needs to send uplink data or it can be configured with configured grant where the UE can send PUSCH periodically with only a set of predefined resource blocks without any PDCCH allocation i.e. DCI scheduling . Both these approaches can help in certain situations but will not help when the cell is loaded and when there are a lot of users on the cell, and the gNB will have lower the resources to allocate to all UE’s for PUCCH. So in another approach the network can configure the UE to send an indication in uplink when it has to send an uplink data on PUCCH and then the network can allocate PUSCH resources to UE to send uplink data.
A unique analogy for SR would be a student raising their hand in class to ask the teacher a question. The student is the UE, the teacher is the gNB, and the question is the UL data. When the student raises their hand, they are essentially sending an SR message to the teacher. The teacher then decides whether or not to call on the student, which is analogous to the gNB granting or denying an UL grant.
Scheduling request is a lower layer i.e MAC layer process. The MAC entity may be configured with zero, one, or more SR configurations.
SR Configurations consists of a set of
- PUCCH resources
- Scheduling requests for different BWP’s
- Per cell i.e Primary node and secondary node (eg- NR-DC)
- For a Logical channel
- Scell beam failure recovery
- and for consistent LBT failure recovery
The network configures Scheduling request Configuration to UE, it specifics the periodicity and the PUCCH resource the UE can use when sending scheduling requests.
The UE Can be configured with Multiple Logical channels and each logical channel can be mapped with SchedulingRequestID, Multiple logical channels can have Multiple SchedulingRequestID’s mapped or Multiple logical channels can be mapped to a single SchedulingRequestID.
Typically if UE has been configured to send Multiple types of data such Low latency, Voice Calls and regular data traffic then it can be configured with Multiple Logical channels.
RRC configures the following parameters for the scheduling request procedure:
- schedulingRequestId (unique ID per SR configuration)
- sr-ProhibitTimer (per SR configuration)
- sr-TransMax (per SR configuration)
SchedulingRequestConfig
The IE SchedulingRequestConfig is used to configure the parameters, for the dedicated scheduling request (SR) resources.
When UE receives the SR Configuration, It will know how many SR resources has been assigned to it, the corresponding PUCCH resource to be used. sr-TransMax indicates the maximum number of times a UE is allowed to send SR if there is no response from gNB. sr-ProhibitTimer indicates the time in ms a UE has to wait before it can transmit the next SR. Once UE transmits an SR it starts a local timer as indicated in sr-ProhibitTimer , the timer is stopped if it receives a UL grant for the SR transmitted. If the sr-ProhibitTimer expires the UE will send another SR. This process continues until the UE has reached maximum SR transmission allowed .
| SchedulingRequestConfig field descriptions |
|---|
| schedulingRequestToAddModList List of Scheduling Request configurations to add or modify |
| schedulingRequestToReleaseList List of Scheduling Request configurations to release. |
| SchedulingRequestToAddMod field descriptions |
|---|
| schedulingRequestId Used to modify a SR configuration and to indicate, in LogicalChannelConfig, the SR configuration to which a logical channel is mapped and to indicate, in SchedulingRequestresourceConfig, the SR configuration for which a scheduling request resource is used. |
| sr-ProhibitTimer Timer for SR transmission on PUCCH in TS 38.321 . Value is in ms. Value ms1 corresponds to 1ms, value ms2 corresponds to 2ms, and so on. When the field is absent, the UE applies the value 0. |
| sr-TransMax Maximum number of SR transmissions as described in TS 38.321. Value n4 corresponds to 4, value n8 corresponds to 8, and so on. |
Below is an illustration of Logical Channel config mapped to Scheduling request Configuration
Every LogicalChannelConfig has a SchedulingRequestID mapped along with LogicalChannelSR-mask and LogicalChannelSR-DelayTimerApplied IE’s.The LogicalChannelSR-mask controls scheduling request triggering for the logical channel when it has configured uplink grant of either Type1 or Type2.
If configured uplink grant is available for the logical channel then UE can send PUSCH in uplink during the configured grant period. If the LogicalChannelSR-mask is set to ‘true’ then SR masking is set to be configured for this logical channel i.e UE can transmit scheduling request for this logical channel if there is any data in MAC buffer and the UE cannot wait until the configured uplink grant period occurs. This situation might happen when Logical Channel is associated with low latency data and the configured uplink grant has a large periodicity to avoid delays in sending UL data UE can trigger SR request for this logical channel data.
The IE logicalChannelSR-DelayTimerApplied indicates whether to apply the delay timer for SR transmission for the logical channel. This flag activates a timer which is used to delay the transmission of SR which is included in BSR config i.e logicalChannelSR-DelayTimer .
If the flag is Set to true if logicalChannelSR-DelayTimer is included in BSR-Config an Set to false if logicalChannelSR-DelayTimer is not included in BSR-Config.
SchedulingRequestResourceConfig
The IE SchedulingRequestResourceConfig determines physical layer resources on PUCCH where the UE may send the dedicated scheduling request
| SchedulingRequestResourceConfig field descriptions |
|---|
| periodicityAndOffset SR periodicity and offset in number of symbols or slots (see TS 38.213 , clause 9.2.4) The following periodicities may be configured depending on the chosen subcarrier spacing: SCS = 15 kHz: 2sym, 7sym, 1sl, 2sl, 4sl, 5sl, 8sl, 10sl, 16sl, 20sl, 40sl, 80sl SCS = 30 kHz: 2sym, 7sym, 1sl, 2sl, 4sl, 8sl, 10sl, 16sl, 20sl, 40sl, 80sl, 160sl SCS = 60 kHz: 2sym, 7sym/6sym, 1sl, 2sl, 4sl, 8sl, 16sl, 20sl, 40sl, 80sl, 160sl, 320sl SCS = 120 kHz: 2sym, 7sym, 1sl, 2sl, 4sl, 8sl, 16sl, 40sl, 80sl, 160sl, 320sl, 640sl sym6or7 corresponds to 6 symbols if extended cyclic prefix and a SCS of 60 kHz are configured, otherwise it corresponds to 7 symbols. For periodicities 2sym, 7sym and sl1 the UE assumes an offset of 0 slots. |
| phy-PriorityIndex Indicates whether this scheduling request resource is high or low priority in PHY prioritization/multiplexing handling (see TS 38.213 , clause 9.2.4). Value p0 indicates low priority and value p1 indicates high priority. |
| resource ID of the PUCCH resource in which the UE shall send the scheduling request. The actual PUCCH-Resource is configured in PUCCH-Config of the same UL BWP and serving cell as this SchedulingRequestResourceConfig. The network configures a PUCCH-Resource of PUCCH-format0 or PUCCH-format1 (other formats not supported) (see TS 38.213 , clause 9.2.4) |
| schedulingRequestID The ID of the SchedulingRequestConfig that uses this scheduling request resource. |