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 ?".
SR carries only one bit of information: whether the UE wants to transmit or not. Everything else comes from configuration. RRC tells the UE which PUCCH resource to use and in which subframes, and MAC decides when to send SR and when to give up and use RACH instead.
Followings are the topics to be covered in this page.
- How UE send SR message ?
- Overall Sequence of SR based Scheduling
- What would happen if UE is not getting any UL grant after SR ?
- Who is controlling this SR process ?
- RRC Parameters
- Reference
How UE send SR message ?
UE send it on a PUCCH (not on PUSCH : 36.321 signals SR only in a TTI where the UE has no UL-SCH resource). 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.
Let's make the PUCCH part concrete. For PUCCH format 1, 36.211 carries the information by the presence or absence of the PUCCH transmission. So a UE with a positive SR transmits on its SR resource, and a UE with a negative SR transmits nothing there. When only a positive SR is transmitted, 36.213 clause 10.1 says the UE uses PUCCH Format 1 on the SR resource.
SR often falls in the same subframe as HARQ-ACK. For FDD with PUCCH format 1a/1b, the UE then sends the HARQ-ACK on its SR PUCCH resource for a positive SR, and on its normal HARQ-ACK resource for a negative SR. The eNB therefore reads the SR from the resource it detects energy on. With PUCCH format 3, 4 or 5, the SR becomes one extra bit appended to the HARQ-ACK bits, where 1 means positive SR and 0 means negative SR.
SR is on/off keying : the UE transmits PUCCH format 1 on its SR resource only for a positive SR.SR can ride with HARQ-ACK : with format 1a/1b the resource choice carries the SR, and with format 3, 4 or 5 one extra bit carries it.SR is not on PUSCH : a UE that already has a PUSCH grant reports its buffer with a BSR instead.
Overall Sequence of SR based Scheduling
SR is only the first step of an uplink transmission. The UE still needs a grant, a PUSCH and HARQ feedback, and some of the gaps between these steps are fixed while others are not.
What would happen when UE send SR to NW (eNB). Following is a simplified and typical procedure happening when UE send SR to eNB.
The diagram reads from top to bottom. The UE sends SR on PUCCH, and the network answers with an UL grant in DCI 0. The UE then sends user data on PUSCH, and the network returns ACK or NACK on PHICH. If the answer is NACK, the UE performs a retransmission.
Look at the two callouts, because they mark different kinds of timing. The gap between SR and the UL grant is an eNB decision. Some eNBs and eNB simulators use 4 ms there, but 3GPP does not specify it. The gaps from UL grant to PUSCH and from PUSCH to PHICH are 4 subframes each for FDD, and 3GPP does specify them. For TDD, these gaps depend on the UL/DL configuration, which is why the links below separate FDD and TDD.
For further details and explanations on SR Based Scheduling, refer to following notes :
- For FDD, refer to Non-Persistant Scheduling for PUSCH transmission.
- For TDD, refer to SR/DCI 0 Timing, DCI 0/PUSCH Timing
SR to grant is not specified : the delay depends on the eNB scheduler.Grant to PUSCH is 4 subframes in FDD : the UE sends PUSCH 4 subframes after the DCI 0.PUSCH to PHICH is 4 subframes in FDD : the HARQ feedback for the PUSCH arrives 4 subframes later.
What would happen if UE is not getting any UL grant after SR ?
SR has no acknowledgement of its own, so the UE can only judge from the grant it receives. The UE therefore needs a rule for how long to keep trying on PUCCH, and what to do after that.
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)
36.321 clause 5.4.4 gives the details. Each SR on PUCCH increments SR_COUNTER. When SR_COUNTER reaches dsr-TransMax, the MAC entity notifies RRC to release PUCCH and SRS for all serving cells. It also clears any configured downlink assignments and uplink grants. It then initiates a Random Access procedure on the SpCell and cancels all pending SRs.
Note what this Random Access procedure is. It is the MAC Random Access procedure of 36.321 clause 5.1, not an RRC connection re-establishment. The RRC connection stays, but the UE has lost its PUCCH and SRS configuration. So the UE needs a new PUCCH and SRS configuration from RRC before it can send SR on PUCCH again.
dsr-TransMax limits the SR attempts : the value n4 means 4 transmissions, n8 means 8, and so on.Giving up releases PUCCH and SRS : RRC must configure them again before the next SR on PUCCH.RACH replaces SR : the UE requests UL resources through the Random Access procedure instead.
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)
Follow the flow chart from the top. When data arrives and no other SR is pending, the MAC entity sets SR_COUNTER to 0. If no PUCCH resource for SR is configured, the MAC entity initiates the RACH process directly. Otherwise, it waits for an SR opportunity outside a measurement gap and with sr-ProhibitTimer not running. At that point, if SR_COUNTER is below dsr-TransMax, it increments SR_COUNTER, instructs PHY to send SR and starts sr-ProhibitTimer. If SR_COUNTER has reached dsr-TransMax, it takes the release and RACH path described in the section above.
The flow chart does not show when an SR stops being pending. In 36.321 v19.3.0, all pending SRs are cancelled when a MAC PDU is assembled that includes a BSR with the buffer status up to the last event that triggered a BSR. They are also cancelled when the UL grant can carry all pending data. So a successful grant ends the SR process, and the BSR tells the eNB how much more to schedule.
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.
MAC decides, PHY transmits : PHY only sends the SR when MAC instructs it.sr-ProhibitTimer spaces the attempts : a new SR waits until the timer from the last SR has stopped.The BSR ends the SR : pending SRs are cancelled once a MAC PDU with the BSR is assembled.
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)
Following is based on
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
}
SchedulingRequestConfig-v1530 ::= CHOICE {
release NULL,
setup SEQUENCE {
sr-SlotSPUCCH-IndexFH-r15 INTEGER (0..1319) OPTIONAL, -- Need OR
sr-SlotSPUCCH-IndexNoFH-r15 INTEGER (0..3959) OPTIONAL, -- Need OR
sr-SubslotSPUCCH-ResourceList-r15 SR-SubslotSPUCCH-ResourceList-r15 OPTIONAL, -- Need OR
sr-ConfigIndexSlot-r15 INTEGER (0..36) OPTIONAL, -- Need OR
sr-ConfigIndexSubslot-r15 INTEGER (0..122) OPTIONAL, -- Need OR
dssr-TransMax-r15 ENUMERATED {
n4, n8, n16, n32, n64, spare3, spare2, spare1}
}
}
SchedulingRequestConfigSCell-r13 ::= CHOICE {
release NULL,
setup SEQUENCE {
sr-PUCCH-ResourceIndex-r13 INTEGER (0..2047),
sr-PUCCH-ResourceIndexP1-r13 INTEGER (0..2047) OPTIONAL, -- Need OR
sr-ConfigIndex-r13 INTEGER (0..157),
dsr-TransMax-r13 ENUMERATED {
n4, n8, n16, n32, n64, spare3, spare2, spare1}
}
}
MAC-MainConfig ::= SEQUENCE {
...,
[[ sr-ProhibitTimer-r9 INTEGER (0..7) OPTIONAL -- Need ON
]],
...
[[ shortTTI-AndSPT-r15 CHOICE {
release NULL,
setup SEQUENCE {
...
ssr-ProhibitTimer-r15 INTEGER (0..7) OPTIONAL -- Need ON
}
} OPTIONAL, -- Need ON
...
]],
...
[[ offsetThresholdTA-r17 SetupRelease {OffsetThresholdTA-r17}
OPTIONAL, -- Need ON
sr-ProhibitTimerOffset-r17 SetupRelease {SR-ProhibitTimerOffset-r17}
OPTIONAL -- Need ON
]]
}
SR-ProhibitTimerOffset-r17 ::= ENUMERATED {
ms90, ms180, ms270, ms360,
ms450, ms540, ms1080, spare
}
The listing now follows 36.331 v19.3.0 and adds the IEs that were missing. SchedulingRequestConfigSCell-r13 configures SR on the PUCCH of an SCell, for PUCCH on SCell. SchedulingRequestConfig-v1530 configures SR for short TTI on SPUCCH, with its own counter limit dssr-TransMax-r15. In MAC-MainConfig, the Release 15 group adds ssr-ProhibitTimer-r15 for SPUCCH, and the Release 17 group adds sr-ProhibitTimerOffset-r17.
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.
Let's work through one value. With sr-ConfigIndex = 17, the table gives SRPERIODICITY = 20 ms and NOFFSET,SR = 17 - 15 = 2. The condition is then (10 x nf + floor(ns/2) - 2) mod 20 = 0. This holds in subframe 2 of every even SFN, so the UE has one SR opportunity every 20 ms. In 36.331, the values 156 and 157 are not applicable for Release 8, and in 36.213 v19.4.0 the table title ends with "for subframe-SR".
dsr-TransMax : Maximum number of SR transmission count (See 36.321 5.4.4 Scheduling Request)
sr-ProhibitTimer : Timer for SR transmission on PUCCH, in number of SR periods of the shortest SR period of any serving cell with PUCCH. The value 0 means that the timer handling of 36.331 clause 7.3.2 applies, so the timer starts and expires immediately. If sr-ProhibitTimerOffset is present, the actual value of sr-ProhibitTimer is CEIL (sr-ProhibitTimerOffset / SR period) + the signalled value of sr-ProhibitTimer.
sr-PUCCH-ResourceIndexP1 : PUCCH resource for antenna port P1, when the UE transmits SR on two antenna ports. E-UTRAN configures it only if sr-PUCCH-ResourceIndex is configured.
sr-ConfigIndex sets when : it gives the SR period and the subframe offset through 36.213 Table 10.1.5-1.sr-PUCCH-ResourceIndex sets where : it selects the PUCCH format 1 resource.dsr-TransMax and sr-ProhibitTimer set how often : they limit the number of attempts and the spacing between them.
Reference
[1] 3GPP TS 36.321 v19.3.0 - clause 5.4.4 Scheduling Request
[2] 3GPP TS 36.213 v19.4.0 - clause 10.1.5 Scheduling Request, SR, procedure, and Table 10.1.5-1
[3] 3GPP TS 36.331 v19.3.0 - SchedulingRequestConfig and MAC-MainConfig with their field descriptions
[4] 3GPP TS 36.211 v19.3.0 - clause 5.4.1 PUCCH formats 1, 1a and 1b