UE上報BSR，期望網絡參照BSR，下發UL grant給UE以便發送UL data，正常情況下，整個過程都會比較順利。但是世事難料，網絡難免有自己的小脾氣或者發送BSR不太順暢，導致UE沒有得到自己想要的東西，那UE的情緒多少會發生變化(難道是嫌棄我太啰嗦？)，等達到一定的界限，UE就會換用一種簡潔的方式通知網絡側，自己有UL data要發送，那就是SR，BSR觸發SR的情景在BSR中有說明。其實UE也指示按規定做事，畢竟UE所有的參數都是網絡側配的，UE能做的，都在網絡的掌握之中，到最后UE和網絡其實也只是在spec搭的舞臺上演戲而已。那這篇就看看SR，先看下SR的配置。

SR用于UE向網絡側要UL grant。MAC entity可以配置有零個、一個或多個 SR configuration。SR configuration由一組PUCCH resources組成，不同的BWP和Cell的SR對應不同的PUCCH resource。對于每個邏輯信道或 SCell BFR和consistent LBT failure recovery場景，每個 BWP 最多配置一個用于發送SR 的PUCCH resource。

每個 SR 配置對應一個或多個邏輯信道和/或 SCell BFR和/或consistent LBT failure recovery。每個邏輯信道、SCell BFR和consistent LBT failure recovery可以映射到零個或一個SR配置，具體由RRC配置。觸發BSR或 SCell BFR或consistent LBT failure recovery（如果存在此類配置）的邏輯信道的 SR 配置就用于相應SR的發送。任何 SR 配置都可以用于由Pre-emptive BSR觸發的 SR。這段內容晦澀難懂，一堆規定，放在這就好，直接看下實際配置。

SR的時頻域資源

通過上述結構使得schedulingRequestId與logical channel進行綁定。例如左圖，LogicalchannelIdentity 2 屬于LCG 0，LCG0與schedulingRequestID 0綁定，進行確定LogicalchannelIdentity 2與schedulingRequestID 0的關系，之后發送SR時就需要用schedulingRequestID 0對應的資源進行發送。

SR時頻域資源這塊的內容摘自之前的PUCCH部分，主要是RRC層schedulingRequest的時頻域配置，包含SR的發送周期及偏移、發送SR所用的PUCCH resource等，SR發送的時頻域資源等規定，這里簡短過一下。

periodicityAndOffset：SR 的發送周期及偏移，例如periodicityAndOffset sl40 : 38 ，即每40個時隙 發一次，要在第39個時隙傳輸SR（index 0~39）；具體配置時還要考慮SCS，不同的SCS可用的配置不同，如下。

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

sym6僅僅在SCS =60 kHz及extended cyclic prefix時才能使用；對于發送周期不大于1個 slot的情況，offset默認為0 slot。

phy-PriorityIndex-r16：指示在物理層處理SR時的優先級，p0 代表low priority, p1代表high priority。沒有配置時默認priority 0。用于物理層處理PHY 優先級或復用時的優先級參考。

resource：UE發送SR時要使用的PUCCH resource id,對于SR，只能配置PUCCH-format0或PUCCH-format1。

schedulingRequestID：The ID of the SchedulingRequestConfig that uses this scheduling request resource.

periodicityAndOffset可以提供SR_periodicity 和SR_offset。如果SR_periodicity 大于1個時隙時，SR 的具體發送時刻由上面的藍色公式決定；如果SR_periodicity =1個時隙，這時候SR_offset應該配置為0，則每個時隙都是SR 的發送時刻；如果SR_periodicity <1個時隙,SR 的發送時刻對應的符號l 由公式 （l-l0 mod SR_periodicity）mod SR_periodicity=0 決定，其中l0是PUCCH format中配置的startingSymbolIndex。

SR 的發送要對應UL symbol，如果SR 的PUCCH transmission occasion可用的symbol小于對應 PUCCH format的nrofSymbol，那UE就不能在這個slot發送SR。

一個SR發送的例子，SR 對應PUCCH format 1一個時隙內對應時頻域示圖如下：

SR發送周期及偏移periodicityAndOffset sl40 : 38 ，即每40個時隙 傳一次，要在第39個時隙傳輸SR（index 0~39）。

從log中看到UE 在frame 573 slot 18 用PUCCH format 1 發送了SR，根據38.213 9.2.4中確定SR發送時機的公式，可知frame 573 slot 18滿足公式，確實是可以發送SR（SCS=30khz N_frame_slot =20），計算過程如下。

SR的工作流程

下面先看下網絡側給UE配置的SR參數，相關參數的RRC 配置結構如下

schedulingRequestId： 用于修改SR配置，在LogicalChannelConfig中指示邏輯信道映射到的SR配置，在SchedulingRequestresourceConfig中指示SR使用的具體資源。

sr-ProhibitTimer：在PUCCH上發送SR 傳輸的定時器。以毫秒為單位。ms1 對應 1ms，ms2 對應 2ms，依此類推。當該字段不存在時，UE 用value 0，在發送完一個SR后開啟，其運行期間，不能再次發送SR。

sr-TransMax：最大的SR發送次數， n4 代表 4個, n8 代表 8次。

其余部分就是SR一系列的規定主要在38.321 5.4.4。

SR 的觸發

觸發SR 的情況在BSR中有描述，即當前至少一個BSR被觸發且還沒有取消時，logicalChannelSR-DelayTimer沒有run觸發了Regualer BSR：

1 當前沒有UL grant進行傳輸;

2 對于configured ul grant的場景，在logicalChannelSR-Mask=false觸發了regular BSR;

3 觸發BSR 后得到的UL grant還是不夠用于新傳;

上述三種情況都要觸發SR，向網絡側要UL grant。

下面是一些瑣碎的規定。

當 SR 被觸發時，就認為其處于pending狀態，直到被取消。

如果UE觸發了一個 SR并且沒有其他使用相同配置的pending SR ，則MAC entity要將其SR_COUNTER置為 0。

只有在 SR 傳輸時機對應的PUCCH resource處于active BWP 上,才認為這樣的SR transmission是有效的。

SR取消的條件

在發送出去SR后，達到某些條件的情況下，UE感覺到比較滿意的話，就會收起自己的小脾氣，也就會停止SR的發送，具體情況如下

由于BSR而觸發的SR：

1 當包含long/short BSR MAC CE的MAC PDU 被傳輸，那在 MAC PDU 組裝之前由于BSR的原因導致的所有pending SR 應被取消，每個相應的 sr-ProhibitTimer 應停止( long/Short BSR MAC CE包含buffer status是持續到MAC PDU 組裝之前 最后一次觸發BSR前的所有data volume)；此時UE有發送BSR MAC CE的UL grant了，UE好開心，那這種情況下UE就不需要繼續發送SR。

2 另一種情況當UL grant足以發送所有的pending data時，UE欣喜若狂，那所有因BSR發送說觸發的pending SR都會取消，并且對應的sr-ProhibitTimer也應停止，皆大歡喜。

對于不是由于BSR觸發的SR(還有其他情況也會觸發SR，比如BFR場景等等)，serving cell：

(1) 如果此 SR 在 MAC PDU 組裝之前由Pre-emptive BSR 過程觸發，并且包含相關Pre-emptive BSR MAC CE 的 MAC PDU 被傳輸；或者

(2) 如果此 SR 是由 SCell 的BFR觸發且傳輸了 MAC PDU，此 PDU 包括 BFR MAC CE 或Truncated BFR MAC CE(包含此 SCell 的BFR信息)；或者

(3) 如果此 SR 由 SCell 的BFR觸發但是該 SCell 被deactive；或者

(4) 如果此 SR 是由 SCell 的consistent LBT failure recovery觸發且UE正在發送包含SCell consistent LBT failure MAC CE的MAC PDU；或者

(5) 如果此 SR 是由一個 SCell 的consistent LBT failure recovery所觸發且該 SCell 的所有觸發的consistent LBT failure都被取消 ：

發生以上任意情況時 ，UE MAC也要取消pending SR并停止相應的sr-ProhibitTimer(在run的話)。

觸發RA 的情況

但是有些時候，事情并不會進行的特別順利，UE發送完SR后，仍然沒有得到UL grant，這時候UE就會換一種強硬的方式繼續未完成的任務，這個新的方式就是RA。

由SR觸發RA的情況有兩種：

第一種情況：只要至少一個SR處于pending狀態且當前沒有有效的PUCCH resource 用于發送Pending SR，UE就要取消pending SR并初始化RA過程。

第二種情況就是下面的描述，協議上描述的很復雜，條件很多，簡單的說就是SR 達到最大發送次數了，SR這個手段行不通了，UE就要觸發RA：

至少一個SR處于pending狀態，當前有有效的PUCCH resource用于發送Pending SR，且在SR transmission occasion 期間sr-ProhibitTimer沒有run外加SR transmission occasion沒有和measurement gap overlap時：

1 SR transmission occasion對應的PUCCH resource沒有與UL-SCH resource overlap或者

2 有配置lch-basedPrioritization ，SR transmission occasion對應的PUCCH resource沒有和RAR UL grant對應的PUSCH或MSGA payload對應的PUSCH或TC-RNTI加擾的UL grant對應的PUSCH overlap，但是pending SR對應的transmission occasion與其他UL-SCH resources overlap時(但觸發SR的邏輯信道的優先級比這個UL SCH resource 高)，只要UE可以在一個valid PUCCH resource上發送SR，那觸發SR的邏輯信道的優先級是最高的(lch-basedPrioritization存在時，在grant(configured grant和dynamic grant)之間產生overlap或發送SR的PUCCH resource和grant(包括configured grant和dynamic grant)之間產生overlap時，MAC entity會根據LCH priority，UE按照上面的規則處理相關問題)；

滿足上述任一條件都可以認為這個SR 傳輸是一個prioritized SR transmission，與SR傳輸PUCCH資源overlap的其他UL grant是de-prioritized UL grant。

否則認為這個SR 是一個 de-prioritized SR transmission。

R15這部分，只有SR transmission對應的PUCCH resource與其他任何UL-SCH resource 沒有產生overlap時，才能發送SR；R16這部分如上，對SR的發送情況進行了細化，即使SR對應的PUCCH resource與其他UL-SCH resource產生overlap時，只要基于LCH priority判斷結束后，SR對應的PUCCH resource是prioritized SR transmission，仍然可以進行候選SR的發送，具體如下(R17基本和R16類似)。

假如SR 傳輸是一個prioritized SR transmission，與其參數overlap的其他UL grant就是de-prioritized UL grant：

如果de-prioritized UL grant 是configured UL grant(有配置autonomousTx) 且對應的PUSCH已經開始發送，UE要停止對應HARQ process 的configuredGrantTimer。

如果此時SR_COUNTER

如果SR_COUNTER>=sr-TransMax,UE 要通知RRC release serving cell的PUCCH/SRS，清除configured DL assignments/UL grant 和semi-persistent CSI report on PUSCH 資源,最后取消所有SR 并觸發RA過程。

SR 觸發的RA 過程停止條件

UE換用RA的方式后，可能會得到網絡側比較完美的答復，那UE就沒有必要繼續糾纏，這時候UE可能會停止RA。對應的場景對應下面三段描述。

由于 BSR 而觸發的pending SR(該 SR 由 MAC entity在MAC PDU 組裝之前由于沒有配置有效的PUCCH resource觸發)，如果：

(1)MAC PDU可以使用UL grant傳輸，但這個UL grant不是RAR提供的UL grant，也不是2-step中用于傳輸MSGA payload的UL grant，并且該PDU包括 BSR MAC CE(BSR 包含的是持續到MAC PDU 組裝之前 最后一次觸發BSR前的所有data volume) ；或者

(2)UL grant(s) 可以用于傳輸所有的UL pending data。

滿足上述情況之一，MAC entity可能會停止（如果有的話）正在進行的RA過程。

由于 SCell BFR觸發的pending SR,由于沒有有效的PUCCH resource 而觸發RA，如果：

(1)MAC PDU可以使用UL grant傳輸，但這個UL grant不是RAR提供的UL grant，也不是2-step中用于傳輸MSGA payload的UL grant，并且該PDU包括 BFR MAC CE(包含SCell BFR info) ；或者

(2)由于Scell被deactive導致所有觸發的scell BFR被取消。

滿足上述情況之一，MAC entity可能會停止(如果有的話)正在進行的RA過程：

由于 consistent LBT failure觸發的pending SR，由于沒有有效的PUCCH resource而觸發RA，如果：

(1)MAC PDU可以使用UL grant傳輸，但這個UL grant不是RAR提供的UL grant，也不是2-step中用于傳輸MSGA payload的UL grant，并且該PDU包括 LBT failure MAC CE(包含SCell consistent LBT failure info)；或者

(2)由于Scell 被deactive 導致所有觸發的consistent LBT failure被取消。

滿足上述情況之一，MAC entity可能會停止（如果有的話）正在進行的RA過程。

最后針對上述內容整理如下流程圖，不用懷疑的是，這個圖有問題，并沒有完整顯示上述內容，只是簡單記錄了大體流程。

至此本篇就基本結束了，不管什么道路都難免崎嶇不平，UE也一樣，即使換用SR后，也可能無法得到UL grant，那就只能觸發RA，但是就算是RA，在某些場景下，UE可能仍然無法得到自己想要的東西，在這種情況下，UE只能按照spec的規定拿出最后一套動作......