SR (Scheduling Request)


SR is a special Physical Layer message for UE to ask Network to send UL Grant (DCI Format 0) so that UE can transmit PUSCH. Putting it other way, SR is an Uplink Physical Layer message from UE to Network, saying "I have some data to send to you. Would you send me some Grant (DCI 0) for me to send the data ?".




How UE send SR message ?


UE send it on a PUCCH (or on UCI part on PUSCH). Not all PUCCH format can carry the SR. Some PUCCH format can carry SR and some other don't. UE is using a certain PUCCH format depending on situations to send SR. (For the detailed PUCCH format that can carry SR, refer to PUCCH format page).


Another implication of SR being a physical layer message imply that you would not be able to decode this with RRC/NAS ASN decoder. Many of eNB or test equipment would let you convert its log into wireshark file, but it is highly likely that you would not see the SR message in the wireshark unless the equipment vendor provide specific wireshark delimiter. Usually those equipment vendor provide their own log viewer that enables this kind of lower layer message.




Overall Sequence of SR based Scheduling


What would happen when UE send SR to NW (eNB). Following is a simplified and typical procedure happening when UE send SR to eNB.




For further details and explanations on SR Based Scheduling, refer to following notes :




What would happen if UE is not getting any UL grant after SR ?


As illustrated above, UE is expecting to get UL Grant after it sends SR to eNB. What if UE does not receive UL grant after it sends SR (because eNB does not UL grant or UE fail to decode UL grant that eNB sent) ? The first reaction on UE side is to transmit SR several more times and if UE does not get any UL grant, it trigger RACH process to re-establish radio connection and get the resource for PUSCH transmission. (NOTE : How many times UE is allowed to retransmit SR before triggering RACH is specified by the RRC parameter dsr-TransMax)




Who is controlling this SR process ?


Even though SR message itself is a kind of physical layer message, it is controlled by MAC layer process (it is similar to many other physical layer channel are controlled by MAC layer)

Overall SR process (when to send SR) is controlled by MAC layer as illustrated below. (See 36.321 5.4.4 for details)



Once SR is transmitted and eNB recieves it, eNB should send UL Grant(DCI 0) and UE has to send PUSCH in response to the UL Grant. The timing among SR, UL Grant, PUSCH varies on whether it is FDD or TDD. 




RRC Parameters


The timing and physical control channel configuration for SR transmission can be configured in higher layer signaling message (e.g, RRC Connection Setup as shown below)


SchedulingRequestConfig ::= CHOICE {

    release NULL,

    setup SEQUENCE {

        sr-PUCCH-ResourceIndex INTEGER (0..2047),

        sr-ConfigIndex INTEGER (0..157),

        dsr-TransMax ENUMERATED {

            n4, n8, n16, n32, n64, spare3, spare2, spare1}




SchedulingRequestConfig-v1020 ::= SEQUENCE {

    sr-PUCCH-ResourceIndexP1-r10 INTEGER (0..2047) OPTIONAL -- Need OR



MAC-MainConfig ::= SEQUENCE {


    [[ sr-ProhibitTimer-r9 INTEGER (0..7) OPTIONAL -- Need ON





sr-PUCCH-ResourceIndex : PUCCH Resource Location described in 36.213 10.1.5 Scheduling Request (SR) procedure.


sr-ConfigIndex : This IE is used to determine the subframe where SR shall be transmitted based on following table and formula.


< 36.213 Table 10.1.5-1: UE-specific SR periodicity and subframe offset configuration >


UE can transmit SR at there subframe where following condition is met.



dsr-TransMax : Maximum number of SR transmission count (See 36.321 5.4.4 Scheduling Request)