以一個實網中的異常場景開始，大概流程是有UL data要發送，UE觸發BSR->no UL grant->SR->no UL grant->trigger RACH->RACH fail->RLF->RRC reestablishment：簡單描述就是UE觸發BSR，此時沒有UL grant，之后觸發SR，仍然沒有 UL grant，之后觸發RACH，RACH fail引起RLF，引起RRC reestablishment；這個異常場景在弱信號情況下比較常見，其中涉及的具體內容其實是比較多的，這篇就看下BSR的內容，BSR 的內容主要在38.321 5.4.5章節。

開始之前簡單看下BSR和SR的區別：UE通過SR向gNB請求上行資源時，只指明了UE有上行數據需要發送，并沒有指明需要發送的上行數據數量。而BSR的作用是將UE當前buffer中待發送的數據情況通知給gNB，gNB可根據BSR上報的UE buffer的數據量，給UE分配上行資源；換個角度看，UE發BSR時，是通過BSR MAC CE，既然能發BSR，肯定是有UL grant，足夠發BSR，如果沒有UL grant，UE要通過SR向gNB要UL grant，進而UE就要發送SR。接下來看看協議中是如何描述BSR的。

BSR相關的RRC層參數如下

logicalChannelSR-Mask：在配置configured uplink grant of type1 or type2 時用于控制SR 的觸發。True代表對應logical channel有配置SR masking。

logicalChannelSR-DelayTimerApplied：用于指示是否對logical channel 應用SR 傳輸的delay timer;設置為false的話，BSR-Config中就不會包含logicalChannelSR-DelayTimer。

logicalChannelSR-DelayTimer：單位是subframe數，Value sf20 代表20 subframes, sf40 代表40 subframes,以此類推；該timer的作用顧名思義，就是在run期間不能觸發SR。

periodicBSR-Timer：單位是subframe數， Value sf1 代表1 subframes, sf5 代表5 subframes,以此類推。

retxBSR-Timer：單位是subframe數， Value sf10 代表10 subframes, sf20 代表20 subframes,以此類推。

logicalChannelGroup：logical channel group的ID, 代表logical channel 對應的LCG ID。

說到參數LCG ID，那就順帶看下LC 和LCG的關系。實網下根據業務的不同，UE可能建立很多RB，如果為每一個邏輯信道(LC)上報一個BSR，會帶來大量的信令開銷。為了減少這種開銷，和LTE相同，NR引入了邏輯信道組（LCG）的概念，不同的是，NR將LCG個數由LTE的4個擴展到了8個，以滿足NR系統更多樣的業務場景。所以UE是基于LCG上報BSR，而不是為每個邏輯信道上報一個BSR。而邏輯信道的分組是gNB的算法，邏輯信道分組也是為了提供更好的BSR上報機制，一般會將有相似調度需求的邏輯信道放入同一LCG中。例如將相同QCI/priority的邏輯信道放入同一LCG。如下圖logical channel 4/2 分別對應的是LCG 7/0。

既然UE的LCG和邏輯信道的配置是由gNB控制的，那gNB就知道每個LCG包含哪些邏輯信道以及這些邏輯信道的優先級。雖然gNB無法知道一個單獨的邏輯信道的緩存狀態，但由于同一LCG中的邏輯信道有著類似的QoS/priority需求，所以基于LCG上報BSR也可以在一定程度上滿足業務的QoS需求。

下面是38.321中BSR的內容。

BSR是用于向serving gNB 提供 MAC entity中的 UL data volume信息的過程，之后gNB根據BSR 中的UL data volume及自身loading，向UE下發對應的UL grant，用于UE UL 傳輸。

與BSR相關的幾個RRC層參數分別是periodicBSR-Timer；retxBSR-Timer；logicalChannelSR-DelayTimerApplied；logicalChannelSR-DelayTimer；logicalChannelSR-Mask；logicalChannelGroup。

每個logical channel 可以使用 logicalChannelGroup 分配到一個 LCG。LCG 的最大數量為八個。更具體的，MAC entity是根據 RLC和 PDCP中的data volume計算過程確定logical channel可用的 UL 數據量，用于BSR的上報。

BSR 觸發場景（BSR的分類）

(1)屬于某個LCG的邏輯信道的有UL data要發送 ，并且該 UL data對應邏輯信道的優先級高于任何其他LCG有UL data要發送的邏輯信道的優先級或

當所有LCG 邏輯信道都沒有UL data要發送時，某個LCG的邏輯信道有UL data要發送，在這種情況下觸發的BSR叫做 regular BSR；

(2)為了避免UE發送了BSR卻一直沒有收到UL grant的情況，gNodeB為UE配置了一個retxBSR-Timer定時器，當retxBSR-Timer 超時并且某個LCG的至少一個邏輯信道有UL data要發送，在這種情況下觸發的BSR也稱為Regular BSR，目的是使得UE周期性地向gNB更新Buffer Status；

(3)考慮到當regular BSR、padding BSR的觸發條件都不滿足時，網絡側也能知道UE的buffer status，以便后續為UE分配適當UL grant，定義了在periodicBSR-Timer 超時，在這種情況下觸發的BSR稱為Periodic BSR。

(4)UL grant給多了，UL數據組包接收后，還有剩余bits沒用完，就要在對應的資源上加padding(MAC需要用 0 來填充)，那padding bits數大于等于BSR MAC CE 加上其subheader的大小時,觸發的BSR叫做 padding BSR；

當多個邏輯信道同時觸發Regular BSR時，每個邏輯通道各自觸發一個獨立的Regular BSR，最后UE根據LCG 確定具體的buffer上報BSR。接下來看下BSR MAC CE的結構。

BSR MAC CE

如開頭所述，為提高空口效率，BSR并不是為每個LC綁定一個BSR，而是為每個LCG綁定一個BSR，上報時以LCG為單位上報，如上圖的LCG ID用于區分BSR。

BSR MAC CE包含的類型分別是Short BSR/Long BSR/Short Truncated BSR/Long Truncated BSR，分別通過LCID 59～62進行區分。Pre-emptive BSR MAC CE用于IAB場景，不在本篇內容之內。

四種BSR MAC CE的發送與BSR的類型優先序，padding BSR 根據場景的不同可以上報上述四種BSR MAC CE；而Regular BSR和Periodic BSR 只能上報Short BSR/Long BSR MAC CE,具體內容后面再說。

short BSR/short Truncated BSR MAC CE

short BSR和short Truncated BSR MAC CE的結構如上，分別由3 bits的LCG ID及5 bits的Buffer size組成，其中LCG ID對應的是BSR 上報的LCG id；

Buffer size代表PDCP和RLC的data volume 單位是bytes，其中RLC header和MAC subheader不在buffer size的計算范圍內。

short BSR和short Truncated BSR MAC CE的Buffer size為5bits，對應0～31個value，分別代表不同的buffer size value，對應如下。

例如上報的Buffer size index 為18 ，就代表buffer size 實際value在(2014,2806]bytes之間，之后網絡側根據實際loading，下發對應的UL grant即可。

long BSR/long Truncated BSR MAC CE

從MAC CE的結構看LCGi 對應LCG0～LCG7；對于long BSR,當LCGi=1時，代表LCG i的Buffer size field 會上報，也就是BSR MAC CE中會包含其Buffer size field， 當LCGi=0時，代表LCG i 不會有Buffer size field上報，即BSR MAC CE中不會有其Buffer size field。對于Long Truncated BSR，當LCGi=1時，代表LCG i 有pending size要發送， 當LCGi=0時，代表LCG i 沒有pending size要發送，其實功能和long BSR類似。

long BSR/long Truncated BSR的Buffer size對應8bits，其Buffer size index范圍是0254(255 reserved)，代表不同的bytes值。Buffer size field 以LCG i升序排列(LCG 07) 。對于long Truncated BSR，Buffer size的大小有限制，不能超過padding bits數。

由于NR可配置8個LCG，如果將8個LCG緩存數據的大小全部上報給gNB，即使一些LCG中沒有緩存數據，也會造成資源浪費，因此在NR中設計了可變大小的BSR格式。結合上面的描述可以看出，short 和long BSR 的區別就是short BSR的大小是固定的，long BSR 大小可變；其中，Truncated BSR是在上行資源不足以上報 normal BSR時，向網絡側上報部分LCG的信息。

BSR 上報流程

Regulat BSR 和Periodic BSR

對于Regular BSR，如果有logical channel 觸發了BSR且有配置logicalChannelSR-DelayTimerApplied=true，那MAC entity要start/restart logicalChannelSR-DelayTimer；其他情況，不需要開啟logicalChannelSR-DelayTimer，logicalChannelSR-DelayTimer有在running就要停止。

對于Regular BSR和Periodic BSR，當多于一個LCG有UL data 要傳輸時，對于有UL data傳輸的所有LCGs要上報Long BSR;否則，只有一個LCG有UL data要傳輸， 就上報Short BSR。

Padding BSR

對于Padding BSR，對應padding bits大于等于short BSR+subheader的size但是小于long BSR+subheader的size時，

1 恰巧當前不止一個LCG有UL data傳輸時

1.1如果當前padding bits等于Short BSR+subheader，就report 有UL data要傳輸的最高優先級LC 的short Truncated BSR；

1.2 當padding bits大于short BSR+subheader的size但是小于long BSR+subheader的size，就根據LCG 中LC的優先級降序的順序上報Long Truncated BSR(如果出現優先級相同的情況，就根據LCGID升序的順序上報)。

2 如果只有一個LCG有UL data傳輸時，就上報Short BSR。

padding bits大于等于long BSR+subheader的size時，就上報包含所有有UL data傳輸的LCG long BSR。

BSR cancel

當UL grant 足以用于傳輸所有pending的data但不夠額外容納 BSR MAC CE 及其subheader時，可以取消所有觸發的 BSR。當傳輸的MAC PDU包括long或short BSR MAC CE 時，應取消在 MAC PDU 組裝之前觸發的所有 BSR，因為此時的long或short BSR MAC CE對應的buffer status包含MAC PDU assembly之間觸發的BSR內容。

其他規定

當前至少一個BSR被觸發且還沒有取消時，如果當前的UL grant足夠發送BSR MAC CE+subheader，就發送當前的生成功的BSR MAC CE，啟動或重啟 periodicBSR-Timer(所有生成的 BSR 都是long或 short Truncated BSR時 不需要開啟periodicBSR-Timer)，也要開啟retxBSR-Timer。

當前至少一個BSR被觸發且還沒有取消時，logicalChannelSR-DelayTimer沒有run且觸發了Regualer BSR：

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

2 對于configured ul grant的場景，在logicalChannelSR-Mask=false時觸發了regular BSR（比如configured ul grant場景配置的UL grant 不夠了，也要通過SR去要UL grant）;

3 可用于新傳輸的 UL-SCH 資源不滿足發送 經過LCP映射限制過程后的觸發的BSR，意思就是觸發BSR后得到的UL grant還是不夠新傳(LCP 過程其他篇再說);

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

這里就是開篇 UE發送BSR后，沒有收到UL grant 之后觸發SR的理論依據。

即使多個事件已觸發 BSR，一個MAC PDU最多應只能包含一個 BSR MAC CE。

Regular BSR 和Periodic BSR 的優先級高于padding BSR，對于由retxBSR-Timer超時觸發的BSR，MAC entity 認為觸發BSR的LC 的優先級是最高的。即retxBSR-Timer超時引起的BSR的LC要優先處理。

MAC entity應在收到在任何 UL-SCH上傳輸新數據的UL grant后重新啟動retxBSR-Timer。

上面這段描述并沒有特別強制的問題，就描述了下對應情況允許的做法，就列在這里做記錄。

最后各個timer的匯總如下