轉載 原文鏈接（http://blog.csdn.net/m_052148
1.UE申請上行資源的途徑
當UE需要向網側發送數據的時候，必須要有上行RB資源，如果沒有RB資源則需要先向網側申請RB資源。UE有三種方式向網側申請RB資源：
（1）向網側發送BSR。BSR的全稱是Buffer Status Report，即緩存狀態報告。UE可以在MAC層的PDU（即分組數據單元）中插入一個BSR控制單元來告訴網側：我的某個或某幾個邏輯信道組當前有多少數據需要發送，希望你能分配一些RB資源給我。
這種通過發送BSR控制單元的方式，可以讓網側知道UE需要發送的數據量，網側可以針對性的分配RB資源。但是這裏有個問題，UE發送BSR控制單元這個動作本身也是需要上行RB資源的，如果UE沒有任何上行RB資源，也是沒有辦法發送BSR的，那麼這個時候UE就需要下面這種方式向網側發送資源申請。
（2）向網側發送SR。當UE無法發送BSR申請RB資源的時候，可以通過發送SR（Scheduling Request）請求的方式申請資源。因爲BSR是被封裝在MAC PDU裏的，通過PUSCH信道發送到網側，因此需要上行RB資源，而SR信號是可以在PUCCH控制信道中傳輸的，並不需要上行RB資源就可以向網側發出資源的申請。但這種申請方式有個不好的地方是，網側收到的只是一個SR信號，並不知道UE接下來需要上傳多少字節的數據，從而並不清楚該分配多少的資源是合適的，因此後續UE可能仍然需要發送BSR來申請更多的上行資源。網側收到UE的SR請求後，分配多少的RB資源是由設備廠家的算法決定的，一般來說，網側收到SR信號後，分配的RB資源至少能夠滿足BSR的發送。
並不是所有的UE都能發出SR信號。SR是在PUCCH控制信道中傳輸的，資源也是有限的，網側的RRC層也會根據實際需要，只給某些UE配置SR資源。只有配置了SR資源的UE，才能向網側發送SR請求，而沒有被配置SR資源的UE，是無法向網側發送發送SR請求的。如果某個UE既無法發送BSR，又不能發送SR信號，那麼這個UE怎麼申請上行資源呢？這個時候UE就需要發起競爭隨機接入過程了。
（3）發起競爭隨機接入。關於競爭隨機接入過程的目的，我已經在博文《LTE-TDD隨機接入過程（1）-目的和分類》裏詳細介紹過，裏面提到競爭接入的目的之一就是獲取上行RB資源。在這種方式中，UE將在MSG3中插入一個BSR控制單元來告訴網側需要的資源信息。當然，這種方式也是UE迫不得已纔會採用的，畢竟這種方式的時延相對BSR和SR來說是最大的。
UE申請資源的過程，將優先採用BSR的方式，如果不能發送BSR，則採用SR的方式，最後纔會考慮競爭隨機接入的方式。如下面的圖1所示，無論是上面的哪種方式，是SR申請還是競爭隨機接入申請，還是BSR申請，網側實際分配的資源可能都不足以讓UE傳完數據，此時UE會繼續發送BSR來申請更多的資源。本文將詳細描述BSR的相關內容，以後的博文再詳細描寫SR的申請過程。
（圖1）
2.BSR攜帶的信息
上文已經提到，BSR可以向網側申請資源，用於UE的數據上傳。網側收到BSR後，根據BSR攜帶的內容，爲UE分配合適的資源。那麼這裏就有個問題：UE的待傳數據量是動態隨機變動的，比如某個時刻UE需要發送999個字節的數據，而下一秒可能需要發送1000001個字節的數據，這種變化是不確定的，UE怎麼向網側表達這種需求信息呢？最簡單的方法，當然是UE將具體的數字（比如1000001這個數）編碼到BSR的信息裏，但這樣的話，在空口中傳輸的bit位個數就比較多。協議在這裏採用了另一種方式來編碼BSR信息：使用0～63這64個index索引，來代表不同的字節範圍。這樣無論UE有多少數據要發，BSR只需要6個bits的空間就足夠了，減少了空口傳輸的比特位數。而且，UE發送具體的字節數也是沒有意義的，畢竟當eNB爲UE調度資源的時候，UE側BSR的信息有很大的概率已經更新爲其它值了。
BSR攜帶的索引值與字節大小的對應關係具體如圖2所示，index=0表示某個邏輯信道組沒有數據需要發送，index=63表示某個邏輯信道組有超過150K字節的數據需要發送。當UE有30個字節的數據需要發送時，只需要將BSR控制單元的值填爲8。網側在解碼BSR信息後，發現BSR的值等於8，就知道UE側需要發送的數據量在26～31字節之間，爲eNB給UE分配合適大小的資源提供了參考依據。需要注意的是，這裏並不意味着網側就會給UE分配26個字節或31個字節對應的資源，UE也不能做類似的假定。因爲網側在收到BSR後，有可能只會分配極少數量的資源，比如這個例子中，網側可能只會分配10個字節的資源給UE，而不是26個字節也不是31個字節，甚至很多時候，網側在收到BSR後，並不會給該UE分配任何的上行資源。網側如何給某個UE分配資源，是由設備廠家的算法決定的，UE不會也不應該對資源申請的結果做特定大小的假設。
（圖2）
3.邏輯信道組
爲了減少在空口中傳輸的信息比特個數，協議並不是爲每個邏輯信道都綁定一個BSR值，而是爲每個邏輯信道組綁定一個BSR值。上文已經提到，BSR攜帶的是0～63這64種索引值，每個索引值對應不同範圍的字節數目，這個字節數並不是該UE所有待傳的數據量，也不是某個邏輯信道待傳的數據字節數，而是某個邏輯信道組待傳的數據量。每個邏輯信道組都有一個BSR值與其綁定，當UE的某個邏輯信道組有數據需要發送時，就可以上報該邏輯信道組的BSR值。
邏輯信道組（Logic Channel Group，簡稱LCG），顧名思義，就是將一個或多個邏輯信道歸爲一組。RRC在配置每個邏輯信道屬性參數logicalChannelConfig的時候，可以爲該邏輯信道分配相應的LCG ID號logicalChannelGroup，這個ID號的範圍是0～3，也就是說只有4個邏輯信道組，如圖3所示。
（圖3）
雖然邏輯信道的組號LCGID由RRC配置，但協議對其中的某些特定的邏輯信道規定了具體的LCGID值，比如：SRB0、SRB1、SRB2這三個邏輯信道，要固定配置LCGID=0。從這個細節我們也可以看到，雖然邏輯信道組是沒有優先級概念的，但協議還是偏向LCGID0的優先級高於其他LCGID，eNB的RRC在給其他邏輯信道配置LCGID的時候，不應該將DRB的LCGID配置成0。另外，邏輯信道與邏輯信道組的匹配還需要參考該邏輯信道承載業務的QCI，對於優先級比較高的業務，可以將該邏輯信道的LCGID配置爲1。
4.BSR控制單元的格式
UE上報的BSR控制單元（control element）有兩種格式：
（1）當BSR屬於Short BSR（短BSR）或者Truncated BSR（截短BSR）類型時，BSR控制單元固定佔1個字節，只能攜帶1個邏輯信道組的BSR信息。該BSR信息所對應的邏輯信道組ID固定佔用2比特，取值0～3，BSR域固定佔6比特，取值0～63。
（2）當BSR屬於Long BSR（長BSR）類型時，BSR控制單元固定佔3個字節，可以攜帶所有邏輯信道組的BSR信息。因爲協議只規定了4種邏輯信道組，因此不需要再攜帶LCG ID值，從LCG ID0到LCG ID3依次編碼6個比特的BSR域：Buffer Size #0對應LCGID0的BSR值，Buffer Size #1對應LCGID1的BSR值，Buffer Size #2對應LCGID2的BSR值，Buffer Size #3對應LCGID3的BSR值。
兩種格式如下面的圖4所示。
（圖4）
需要注意的是，圖4中的Buffer Size #1和#2是跨字節的，關於跨字節的高低位合併問題，與DCI碼流的高低位合併規則是相同的，詳見博文《LTE下行物理層傳輸機制（5）-DCI格式的選擇和DCI1A》。
每個MAC控制單元都對應着一個MAC子頭，這個子頭裏的LCID域用來表示控制單元的類型。上面提到的BSR的三種類型Short BSR、Truncated BSR、Long BSR，就是通過子頭中的LCID值確定的（關於MAC PDU更詳細的組成結構，後面博文再單獨介紹），如下圖5所示。協議爲這三種BSR類型分別定義了不同的LCID值：如果與控制單元相對應的子頭的LCID值是28（即二進制11100），那麼表示UE上傳的是Truncated BSR，這個時候網側MAC層只需要提取1個字節的控制單元碼流，從中就可以解析出邏輯信道組ID號和BSR值；類似的，如果與控制單元相對應的子頭的LCID值是30，則表示UE上傳的是Long BSR，網側需要提取3個字節的控制單元碼流，從中解析出所有邏輯信道組的BSR值。
（圖5）
5.UE觸發BSR的時機
當以下事件之一發生時，UE將會觸發一個BSR（注意：這裏只是觸發BSR，而不是向網側實際發送一個BSR）：
（1）當屬於某個邏輯信道組的某個邏輯信道有上行數據可供傳輸，並且這條邏輯信道的優先級高於目前任何邏輯信道組中任何邏輯信道的優先級，或者目前同個邏輯信道組中所有其它的邏輯信道均無可傳數據，此時將觸發一個BSR，且該BSR叫做常規BSR（Regular BSR）。如下文的圖6所示，後面還會繼續用到這個圖。
前一個觸發場景的意思是，無論UE之前是不是已經發出了BSR，抑或這個時候還在等待上行授權，只要具有更高優先級的邏輯信道有新數據要傳，那麼這個時候UE就要重新觸發一次BSR。後一個觸發場景的意思是，有一個邏輯信道組之前是沒有數據可傳的，此時其中某個邏輯信道有數據可傳了，那麼不管其他邏輯信道組的狀態是什麼，都要重新觸發一次BSR。
（圖6）
當UE觸發了一個BSR且當前TTI時刻有上行RB可用時，UE將組建BSR控制單元；當UE觸發了一個常規BSR且當前TTI時刻沒有上行RB可用時，是沒有辦法發送BSR的，但是否就需要發送SR申請資源呢？不然，此時還要看下面兩種情況，只有滿足其中之一，纔會通過SR發送資源申請（注：只有當常規BSR不能發送的時候纔會繼續考慮是否通過發送SR來申請資源，而週期BSR和填充BSR不能發送的時候，是不會考慮發送SR的）：
（A）沒有已經配置的上行授權。如果網側激活了UL SPS，那麼認爲該UE的上行授權已經被配置。
（B）常規BSR是由某個邏輯信道有上行數據可傳觸發的，但RRC並沒有配置該邏輯信道的logicalChannelSR-Mask參數。換句話說，如果UE已經觸發了一個常規BSR，且已經配置了上行授權，此時若網側將參數logicalChannelSR-Mask設置爲true，就不會觸發SR。logicalChannelSR-Mask參數屬於邏輯信道的參數，在logicalChannelConfig信元中配置（見上文圖3）。
綜合（A）和（B），當UE觸發了一個常規BSR，且已經配置了上行授權，同時該邏輯信道的logicalChannelSR-Mask爲true，那麼就不需要發送SR。
| 這裏具體說說條件（A）和（B）的由來： 在最初的R9協議版本中，只要觸發了常規BSR且該TTI時刻沒有上行RB可用，就需要通過觸發SR來申請資源，當時並沒有增加（A）和（B）的限制，但後來隨着協議的完善，發現UE在進行UL SPS時這裏是有缺陷的。如果沒有這兩個條件，當UE處於UL SPS狀態時，原本爲了減少信令交互的SPS機制，可能會出現頻繁發送SR申請資源的情況，這個與UL SPS的設計初衷是違背的。舉個例子：UE在DRB1中進行UL SPS數據的週期傳輸，在某個非SPS週期的TTI時刻，DRB1中有新數據可傳，滿足常規BSR的觸發條件，由於還沒有到ULSPS週期的TTI時刻，所以沒有可用的上行RB，此時UE將爲DRB1觸發一個SR過程。但實際上這個時候是不需要觸發SR的，因爲在UL SPS週期時刻到的時候，自然就有了上行RB資源，不需要進行申請。 爲了避免UE在UL SPS狀態時不必要的SR發送，浪費SR資源，以及減少UE監測PDCCH的時間，2009年11月，高通、諾西等多家公司聯合提出了這樣的一個限制方案，從而當UE處於UL SPS狀態的時候，可以控制特定邏輯信道的SR發送。 比如，UE在UL SPS過程中，使用DRB1進行數據的週期上傳，這個時候網側可以將DRB1的logicalChannelSR-Mask設置爲true，那麼UE在配置了UL SPS之後，就不會因DRB1有了新數據而觸發SR過程了。 |
（2）分配有上行資源，並且填充比特數大於或等於BSR控制單元與其MAC子頭的比特數之和，此時將觸發一個BSR，且該BSR叫做填充BSR（Padding BSR）。之所以增加這種機制，主要是基於有效利用資源的考慮。示意圖參考下文的圖7。
（圖7）
（3）重傳定時器retxBSR-Timer超時，並且UE在某個邏輯信道組中的任意一個邏輯信道有可傳數據，此時UE將會觸發一個BSR，且該BSR也叫做常規BSR。
（4）週期定時器periodicBSR-Timer超時，此時UE將會觸發一個BSR，且該BSR叫做週期BSR（Periodic BSR）。之所以增加這種機制，是防止以上條件都不滿足時，eNB側也可以知道UE的資源需求，爲UE分配適當的上行資源。
retxBSR定時器和periodicBSR定時器由RRC配置，可在RRCConnectionSetup、RRCConnectionReestablishment或RRCConnectionReconfiguration消息中的radioResourceConfigDedicated信元的mac-MainConfig字段中帶給UE，如圖8所示。
（圖8）
參數的取值類似於下面的表格所示，單位是子幀或ms，sf320表示320ms。
| mac-MainConfig explicitValue : { ul-SCH-Config { maxHARQ-Tx n4, periodicBSR-Timer sf10, retxBSR-Timer sf320, ttiBundling FALSE } ... ... } |
儘管有多個事件可以觸發BSR，但一個MAC PDU中最多隻能包含一個BSR MAC控制單元，且常規BSR和週期BSR優先於填充BSR的發送。
關於retxBSR定時器和periodicBSR定時器啓動或重啓的時機：
（1）如果UE已經觸發了一個BSR，且在該TTI有新數據傳輸的上行RB資源，那麼除截短BSR外，啓動或重啓periodicBSR定時器。
（2）如果UE已經觸發了一個BSR，且在該TTI有新數據傳輸的上行RB資源，啓動或重啓retxBSR定時器。
（3）一旦UE收到了在UL-SCH上傳輸新數據的授權，則重啓retxBSR定時器。
當上行授權可以滿足所有待傳數據的傳輸，但不足以額外傳輸BSR控制單元及其MAC子頭的比特總和時，UE將取消全部觸發的BSR。當傳輸的MAC PDU中已經包含了BSR，則取消全部觸發的BSR。
前文已經提到，網側收到的BSR控制單元中只有三種類型：長BSR、短BSR和截短BSR，這些是從BSR長度的角度分類的，而常規BSR、填充BSR和週期BSR，則是從BSR觸發原因的角度分類的。這兩種分類之間存在着一定的關係，比如對於常規BSR來說，既可能是長BSR也可能是短BSR，下面具體說說這兩種分類方式之間的關係。
6.常規BSR、填充BSR、週期BSR與短BSR、截短BSR、長BSR的關係
（1）常規BSR
如果UE發送的是常規BSR，且該TTI有超過1個邏輯信道組有可傳數據，那麼上報長BSR，否則上報短BSR。上面圖6的場景1，有3個邏輯信道組有數據可傳，此時上報長BSR；在場景2中，只有1個邏輯信道組有數據可傳，此時上報短BSR；場景3與場景2的觸發原因相同，也是由於LCG-ID1中只有1個邏輯信道5有可傳數據，但因爲LCG-ID0中的邏輯信道0也有可傳數據，所以上報長BSR。
（2）填充BSR
（A）如果填充比特數大於或等於短BSR與其MAC子頭的比特數之和（即2個字節），但小於長BSR與其MAC子頭的比特數之和（即4個字節），那麼：
--------（a）如果上報BSR的TTI時刻有超過1個邏輯信道組的數據可傳，則上報具有最高優先級邏輯信道的邏輯信道組的截短BSR。之所以稱爲截短BSR，是因爲此時有多個邏輯信道組的數據可傳，按理說應該上報長BSR的，但限於可用的填充資源有限，只能發送1個邏輯信道組的BSR，所以定義了這個“截短BSR”，以便於區分一個字節的短BSR。
--------（b）否則，上報短BSR。
（B）否則，如果填充比特數大於或等於長BSR與其MAC子頭的比特數之和，則上報長BSR。此時不需要關心有多少個邏輯信道組有數據可傳，統一向網側報長BSR。
（3）週期BSR
如果UE發送的是週期BSR，且該TTI有超過1個邏輯信道組有可傳數據，那麼上報長BSR，否則上報短BSR，不會上報截短BSR。
我們在討論常規BSR、週期BSR、填充BSR的時候，它的修飾詞常常是“觸發”(trigger)，而在描述長BSR、短BSR、截短BSR的時候，它的修飾詞往往是“發送”（report），注意這裏的區別。上面幾種類型的關係總結如下：
（圖9）
參考文獻：
（1）3GPP TS 36.321 V9.6.0 (2012-03) Medium Access Control (MAC) protocol specification
（2）3GPP TS 36.331 V9.18.0 (2014-06) Radio Resource Control (RRC)