LTE學習筆記HARQ、BSR

1、20140310 HARQ，BSRLTE：上行HARQ（二）      接下來，我們來看看上行是如何進行同步的。      首先需要說明的是，如果UE需要在PUSCH上發(fā)送數(shù)據(jù)，UE需要滿足以下兩個條件之一：      1）收到一個有效的UL Grant：該UL grant可以來自動態(tài)調(diào)度的PDCCH（DCI format 0/4，本文只介紹這種情況）、或來自RAR，或通過半靜態(tài)配置。      2）收到一

2、個PHICH且指示為NACK：對應(yīng)非自適應(yīng)重傳。      接下來，我們分FDD、TDD 16、TDD 0三種配置來介紹上行HARQ在時域上的同步關(guān)系！每種配置都包含2部分：1）UL grant/PHICH與對應(yīng)的PUSCH傳輸之間的timing關(guān)系；2）PUSCH傳輸與對應(yīng)的PHICH（ACK/NACK）之間的timing關(guān)系。1) FDD      對FDD而言，如果UE在子幀n收到了UL grant（DCI format 0/4，對應(yīng)新傳或自適應(yīng)重傳）或PHICH（只收到NACK，對應(yīng)非自

3、適應(yīng)重傳），則UE會在n + 4子幀發(fā)送對應(yīng)的PUSCH。（見36.213的8.0節(jié)）      對FDD而言，如果UE在子幀n收到了PHICH，則該PHICH對應(yīng)UE在上行子幀n - 4發(fā)送的PUSCH。（見36.213的8.3節(jié)）      如圖3所示。圖3：FDD中的上行傳輸，UL grant、PUSCH、ACK/NACK之間的timing關(guān)系子幀n，n+4、n+8、n+12、n+16都對應(yīng)同一HARQ process。只要確定了子幀n所使用的HARQ process number，根據(jù)t

4、iming關(guān)系，也就知道后續(xù)子幀n+4、n+8、n+12、n+16所使用的HARQ process。TDD的情況類似，但是timing關(guān)系略有不同。（注：每個子幀只對應(yīng)一個HARQ process，空分復用的情況下是2個，每個對應(yīng)一個TB。）2) TDD 16      對TDD UL/DL configuration 16而言，如果UE在子幀n收到了UL grant（DCI format 0/4，對應(yīng)新傳或自適應(yīng)重傳）或PHICH（只收到NACK，對應(yīng)非自適應(yīng)重傳），則UE會在n + k子幀發(fā)送對應(yīng)的PUSCH。其中k的值見36.213的Table 8

5、-2（見下圖）。（見36.213的8.0節(jié)）Table 8-2 k for TDD configurations 0-6TDD UL/DLConfigurationsubframe number n0123456789046   46   1 6  4 6  42   4    4 34       444  

6、;      445        4 677   77  5圖4給出了TDD Configuration 1和2下，UL grant/PHICH與對應(yīng)的PUSCH傳輸之間的timing關(guān)系。以TDD Configuration 1為例，如果UE在子幀1收到了UL grant（或PHICH），則UE會在子幀7（n+k=1+6）發(fā)送PUSCH（或重傳）；如果UE在子幀9收到了UL grant（或PH

7、ICH），則UE會在下一系統(tǒng)幀的子幀3（n+k=9+4）發(fā)送PUSCH（或重傳）。圖4：TDD 1/2中，UL grant/PHICH與對應(yīng)的PUSCH傳輸之間的timing關(guān)系（對應(yīng)36.213的Table 8-2）      對TDD UL/DL configuration 1-6而言，如果UE在子幀n收到了PHICH，則該PHICH對應(yīng)UE在上行子幀n - k發(fā)送的PUSCH。其中k的值見36.213的Table 8.3-1（見下圖）。（見36.213的8.3節(jié)）Table 8.3-1 k for TDD configurations 0

8、-6TDD UL/DLConfigurationsubframe number i0123456789074   74   1 4  6 4  62   6    6 36       664        665   

9、     6 664   74  6  圖5給出了TDD Configuration 1和2下，PUSCH傳輸與對應(yīng)的PHICH（ACK/NACK）之間的timing關(guān)系。以TDD Configuration 1為例，如果UE在子幀2發(fā)送了PUSCH，則UE會在子幀6（N-K=6-4）接收對應(yīng)的PHICH；如果UE在子幀7發(fā)送了PUSCH，則UE會在下一系統(tǒng)幀的子幀1（N-K=1-4=7）接收對應(yīng)的PHICH。 圖5：TDD 1/2中，PUSCH傳輸與對應(yīng)的PHIC

10、H（ACK/NACK）之間的timing關(guān)系（對應(yīng)36.213的Table 8.3-1）      圖6舉了一個例子： TDD 1下，假如UE在下行子幀1收到UL grant，對照圖4可知，UE會在上行子幀7發(fā)送PUSCH，進一步對照查圖5可知，UE會在下行子幀1接收PHICH（和UL grant）。如果需要重傳，對照圖4可知，UE會在上行子幀7進行重傳，如此反復！這就是一個完整的HARQ處理流程。 圖6：舉例3) TDD 0      對TDD UL/DL configur

11、ation 0而言，一個系統(tǒng)幀內(nèi)的下行子幀數(shù)少于上行子幀數(shù)。因此，一個下行子幀可能需要同時給2個上行子幀發(fā)送UL grant，為了實現(xiàn)該功能，DCI format 0/4新增了一個2 bit的字段：UL index（見36.212的5.3.3.1.1節(jié)和5.3.3.1.8節(jié)）。與此同時，一個下行子幀可能需要同時反饋2個上行子幀的ACK/NACK信息，為了將不同上行子幀對應(yīng)的PHICH區(qū)分開，又新增了的概念（見36.213的9.1.2節(jié)）。 注意：只有TDD UL/DL configuration 0下的上行子幀4和9對應(yīng)；其它情況下（包括其它TDD配置和FDD），。  對T

12、DD UL/DL configuration 0而言，如果UE在子幀n收到的UL grant的MSB置為1，或在子幀0或5接收到的PHICH對應(yīng)（反饋的不是子幀4或9的ACK/NACK信息），則UE會在子幀n + k發(fā)送對應(yīng)的PUSCH，其中k的值見36.213的Table 8-2。 對TDD UL/DL configuration 0而言，如果UE在子幀n收到的UL grant的LSB置為1，或在子幀0或5接收到的PHICH對應(yīng)，或在子幀1或6接收到PHICH，則UE會在子幀n + 7發(fā)送對應(yīng)的PUSCH。 對TDD UL/DL configuration 0而言，如果U

13、E在子幀n收到的UL grant的MSB和LSB均置為1，則UE會在子幀n + k和n + 7都發(fā)送對應(yīng)的PUSCH。（見36.213的8.0節(jié)） 從圖7中可以看出：在TDD 0中，（1）任意一個下行子幀發(fā)送的UL grant都可能對應(yīng)2個上行子幀發(fā)送的PUSCH；2）某個上行子幀可能得到來自2個下行子幀的UL grant。例如：如果在下行子幀0收到的UL grant的LSB置為1，同時在下行子幀1收到的UL grant的MSB置為1，則對應(yīng)上行子幀7，會收到2個UL grant！關(guān)于1個上行子幀有2個UL grant的情形該如何處理，我沒有找到相關(guān)的介紹。但我這里也有些疑惑：2個U

14、L grant如果調(diào)度到同一塊PRB資源怎么辦？或是2選一？或是eNodeB在做上行調(diào)度時，保證對應(yīng)一個上行子幀只會收到一個UL grant？圖7：TDD 0中，UL grant（PHICH）與對應(yīng)的UL-SCH之間的timing關(guān)系 如圖8所示，下行子幀0需要同時反饋上行子幀3（）和4（）的ACK/NACK信息；下行子幀5需要同時反饋上行子幀8（）和9（對應(yīng)）的ACK/NACK信息。如果UE在對應(yīng)的子幀n收到了PHICH，則該PHICH對應(yīng)UE上行子幀n - k發(fā)送的PUSCH數(shù)據(jù)，其中k的值見36.213的Table 8.3-1；如果UE在對應(yīng)的子幀n收到了PHICH，則該PHI

15、CH對應(yīng)UE上行子幀n - 6發(fā)送的PUSCH數(shù)據(jù)。其中k的值見36.213的Table 8.3-1。（見36.213的8.3節(jié)）圖8：TDD 0中，PUSCH傳輸與對應(yīng)的ACK/NACK之間的timing關(guān)系【舉例】      圖9是一個FDD下，上行HARQ的例子。TDD除了timing關(guān)系不同外，其它處理是一樣的。圖不是很清晰，大家注意一下每個子幀對應(yīng)的虛線。圖9：非自適應(yīng)和自適應(yīng)HARQ操作（FDD）      注：R-10中新增了DCI format 4以支持上行空

16、分復用，此時2個codeword對應(yīng)的是不同的HARQ process，處理方式與之前介紹的相同。但在非自適應(yīng)重傳時，如果接收到的NACK數(shù)與最近接收到的PDCCH指示的TB數(shù)，有特殊處理，大家可以關(guān)注下36.213的8.0節(jié)。因為對DCI format 4沒有太深的了解，這里我就不做介紹了。本文總結(jié)：1） 如何確定是重傳還是新傳？給定某個HARQ process，無論收到的PHICH指示的是ACK還是NACK，只要同時還收到UL grant，則UE會忽略PHICH而使用UL grant來決定如何進行下一次傳輸（新傳還是重傳）。當前子幀或后續(xù)子幀中接收到的UL grant中的NDI來決定是進行

17、重傳（NDI沒有反轉(zhuǎn)），還是進行新傳（NDI反轉(zhuǎn)，此時會清空HARQ緩存區(qū)）。2） 什么時候會清空緩沖區(qū)？是否清空HARQ緩存區(qū)是由UL grant的NDI來決定的。3） 如何確定HARQ process？對于FDD而言，如果上行傳輸模式為TM1，則有8個上行HARQ process；如果上行傳輸模式為TM2，則有上行HARQ process數(shù)將翻倍，為16個，此時每個子幀有2個HARQ process。對于TDD而言，如果上行傳輸模式為TM1，則不同的TDD上下行配置對應(yīng)的上行HARQ process數(shù)見36.213的Table 8-1所示（如下圖）；如果上行傳輸模式為TM2，則有上行HAR

18、Q process數(shù)將翻倍，此時每個子幀有2個HARQ process。 這里我們不考慮子幀綁定（subframe bundling）的場景4） 如何確定冗余版本RV？如果是非自適應(yīng)重傳，UE只會收到PHICH中指示的ACK/NACK信息，而不會顯式地收到RV信息。上行HARQ是同步的，RV遵循一個固定的順序：0, 2, 3, 1（注意：這個順序只對“非自適應(yīng)重傳”有意義）。新傳使用的RV由UL grant指定，值為0；若之后UE收到NACK，則會使用前一次傳輸對應(yīng)的下一個RV版本（對應(yīng)0，下一個RV值為 2；對應(yīng)2，下一個RV值為 3）來發(fā)起重傳，依此類推。如果是自適應(yīng)重

19、傳，則UE不僅會收到PHICH，還會收到PDCCH（UL grant）。如果需要重傳，UE會根據(jù)UL grant的指示來選擇RV（見36.213的Table 8.6.1-1），但不一定是0, 2, 3, 1的順序。如果UL grant中指示的MCS index為028，則RV = 0并使用Table 8.6.1-1中指示的真正的MCS。如果UL grant中指示的MCS index為2931，RV版本見Table 8.6.1-1，并且從表中可以看出，這3個MCS index是預(yù)留的，不攜帶真正的MCS信息，因此如果MCS index為2931，其MCS遵循前一次傳輸使用的MCS（TB size

20、和調(diào)制方式都與前一次傳輸，或者說，最近一次接收到的MCS index為028的UL grant相同）。（見36.213的Table 8.6.1-1）5） 如何確定同步關(guān)系？本章分FDD、TDD 16、TDD 0三種配置來介紹上行HARQ在時域上的同步關(guān)系。每種配置都包含2部分：1）UL grant/PHICH與對應(yīng)的PUSCH傳輸之間的timing關(guān)系；2）PUSCH傳輸與對應(yīng)的PHICH（ACK/NACK）之間的timing關(guān)系。FDDTDD16TDD0UL grantn+4n+kn+k/n+7PHICH（ACK/NACK）n-4n-kn-k/n-66） 上行HARQ中的自適應(yīng)和非自適應(yīng)處理

21、有何不同？1、 如果是非自適應(yīng)重傳，UE只會收到PHICH中指示的ACK/NACK信息。如果是自適應(yīng)重傳，則UE不僅會收到PHICH，還會收到PDCCH（UL grant）。2、 在非自適應(yīng)重傳時，重傳與與前一次傳輸使用相同的PRB資源和MCS。因此下行只需要PHICH這一種控制信令，而不需要PDCCH（UL grant），從而降低了開銷。在自適應(yīng)重傳時是為了避免分割上行頻域資源或避免與隨機接入的資源發(fā)生碰撞。此時eNodeB不僅會發(fā)送PHICH，還會發(fā)送PDCCH（UL grant）以指示重傳所使用的新的PRB資源和MCS。3、 自適應(yīng)重傳/非自適應(yīng)重傳的同步timing時間不一樣。二、HA

22、RQ bundling和HARQ multiplexing 對于TDD，如果UE不支持聚合超過1個serving cell，即非載波聚合的條件下，RRC層可以給UE配置2種ACK/NACK反饋模式。（見36.213的10.1.3節(jié)）1、HARQ-ACK bundling（或稱為HARQ bundling、ACK/NACK bundling）2、HARQ-ACK multiplexing（或稱為HARQ multiplexing、ACK/NACK multiplexing）      可以看出，只有TDD且非載波聚合的情況下，才有HARQ bun

23、dling和HARQ multiplexing的概念。      UE使用HARQ bundling還是HARQ multiplexing是通過PUCCH-ConfigDedicated的tdd-AckNackFeedbackMode字段來配置的。該字段對PUCCH和PUSCH上回復的ACK/NACK均有效。一、HARQ bundling      HARQ bundling：將同一serving cell的多個下行子幀的對應(yīng)同一codeword的ACK/NACK做邏輯與（logical AND

24、）操作，最終得到1 bit（非空分復用，使用PUCCH format 1a）或2 bit（空分復用，使用PUCCH format 1b）的ACK/NACK信息。做HARQ bundling操作的是屬于同一HARQ綁定窗口內(nèi)的個PDSCH傳輸和指示下行SPS釋放PDCCH的子幀，那些沒有發(fā)送PDCCH/PDSCH的子幀是不考慮在內(nèi)的。（根據(jù)每個子幀發(fā)送多少個codeword，即是否使用空分復用，決定發(fā)送多少個bit的信息）      注意：HARQ bundling只用于單個cell的場景。也就是說，載波聚合并不使用HARQ bundling。圖

25、1：HARQ bundling的一個例子      上圖是HARQ bundling的一個例子，空分復用的UE在4個下行子幀接收到的PDSCH對應(yīng)在同一個上行子幀回ACK/NACK。eNodeB在第1、2、4個子幀發(fā)送了PDSCH，對應(yīng)codeword 0，HARQ 反饋分別為NACK/ACK/ACK，則有0 & 1 & 1 = 0；對應(yīng)codeword 1， HARQ 反饋分別為ACK/ACK/ACK，則有1 & 1 & 1 = 1。則在對應(yīng)的PUCCH/PUSCH上做反饋時，會攜帶2 bit的信息01，即對應(yīng)

26、的所有下行子幀的第一個codeword都需要重傳，而第二個codeword不需要重傳。      假定上圖中其他條件不變，eNodeB在第3個子幀（對應(yīng)陰影部分）也發(fā)送了PDCCH和PDSCH，但UE沒有檢測到，此時UE應(yīng)該反饋00。但由于UE不知道eNodeB是否在第三個子幀發(fā)送了數(shù)據(jù)，根據(jù)HARQ bundling的原理，還是會反饋01，這就不對了。為了解決這類問題，LTE提出了DAI的概念，這在之前的博文已經(jīng)介紹。 注意：協(xié)議中的提到 “spatial HARQ-ACK bundling（或spatially-bundled）”

27、與“HARQ-ACK bundling”不是同一個概念。“spatial HARQ-ACK  bundling（或spatially-bundled）”是指將同一小區(qū)，同一下行子幀發(fā)送的2個codeword對應(yīng)的2個ACK/NACK做邏輯與（logical AND）處理，得到1 bit 的ACK/NACK信息。它主要應(yīng)用于HARQ multiplexing、PUCCH format 1b with channel selection和PUCCH format 3。（這只是對單個下行子幀的處理，而HARQ bundling/multiplexing是對整個HARQ綁定窗口的處

28、理）使用HARQ bundling的場景有3種（見36.213的7.3節(jié)）：      （1）tdd-AckNackFeedbackMode設(shè)置為bundling；      （2）tdd-AckNackFeedbackMode設(shè)置為multiplexing，但回應(yīng)ACK/NACK的上行子幀對應(yīng)的M值為1（M的取值見36.213的Table 10.1.3.1-1），即一個上行子幀對應(yīng)一個下行子幀的場景。這種場景至多需要回應(yīng)2 bit（空分復用）的ACK/NACK，如果使用HARQ multipl

29、exing，至多只能攜帶1 bit的信息，反而不如使用HARQ bundling將2 bit的信息都回復給eNodeB（使用PUCCH format 1b）。      （3）對于TDD UL-DL configuration 5且UE不支持聚合超過1個serving cell（即非載波聚合條件下），則該UE只支持HARQ bundling。（見36.213的10.1.3節(jié)）對于HARQ bundling，當UE配置了TM 3/4/8/9并且ACK/NACK在PUSCH上傳輸（注意：不包含PUCCH上回應(yīng)ACK/NACK的情況），則UE總是假定

30、codeword 0和1都使能，并最終生成2 bit的ACK/NACK信息。如果UE在HARQ綁定窗口內(nèi)只在codeword 0檢測到PDSCH傳輸，則UE為codeword 1生成NACK。（關(guān)于codeword使能/去使能，會在后面介紹）      通過之前的介紹，我們可以看出，對于HARQ bundling，只要UE在綁定窗口內(nèi)有一個TB沒有正確接收（NACK/DTX），對應(yīng)該TB所在的codeword，eNodeB就應(yīng)該收到NACK或根本沒收到HARQ反饋，并重傳所有下行子幀對應(yīng)該codeword的數(shù)據(jù)。  

31、0;   由于只需要傳輸1或2 bit的ACK/NACK信息，HARQ bundling能夠提高上行控制信令的UL coverage和capacity（尤其對小區(qū)邊緣的UE）。而不足之處在于eNodeB無法確認哪一個或幾個下行子幀解碼失敗，只好把所有下行子幀的數(shù)據(jù)都重傳一遍，這會導致throughput的下降。二、HARQ multiplexing      HARQ multiplexing：將同一serving cell的同一下行子幀發(fā)送的2個codeword對應(yīng)的ACK/NACK做邏輯與（logical AND）操作（

32、注意：在協(xié)議中，這稱為“spatially bundled”或“spatial HARQ-ACK  bundling”處理，與HARQ bundling不是同一個概念），得到1 bit 的ACK/NACK信息。做HARQ multiplexing操作的是屬于同一HARQ綁定窗口內(nèi)的下行子幀，根據(jù)有多少個子幀發(fā)送了下行數(shù)據(jù)，或M值的大小，決定發(fā)送多少bit的信息。這兩種情況的區(qū)別，見后續(xù)介紹。 圖5：HARQ multiplexing的一個例子      上圖是HARQ multiplexing的一個例子，空分復用的UE在4個

33、下行子幀接收到的PDSCH對應(yīng)在同一個上行子幀回ACK/NACK。eNodeB在第1、2、4個下行子幀發(fā)送了PDSCH，對應(yīng)第1個子幀，2個codeword的HARQ 反饋分別為NACK/ACK，則有0 & 1 = 0；對應(yīng)第2個子幀，2個codeword的HARQ 反饋分別為ACK/ACK，則有1 & 1 = 1；對應(yīng)第3個子幀，沒有下行傳輸，則有0 & 0 = 0（注意：這個0可能發(fā)送，也可能不發(fā)送，這會在后續(xù)介紹）；對應(yīng)第4個子幀，2個codeword的HARQ 反饋分別為ACK/ACK，則有1 & 1 = 1。則在對應(yīng)的PUCCH/PUSCH上做反饋時，

34、會攜帶3 bit（或4 bit）的信息011（或0101），即第1個下行子幀的2個codeword都需要重傳。 使用HARQ multiplexing的場景：tdd-AckNackFeedbackMode設(shè)置為multplexing，且反饋ACK/NACK的上行子幀對應(yīng)的M值為大于1（M的取值見36.213的Table 10.1.3.1-1），即一個上行子幀對應(yīng)多個下行子幀的場景。（見36.213的7.3節(jié)）      對于TDD UL-DL configuration 5且UE不支持聚合超過1個serving cell（即非載波聚合條件下），

35、則該UE只支持HARQ bundling，而不支持HARQ multiplexing。（見36.213的10.1.3節(jié)）總結(jié)：參考二、Buffer Status Report（BSR）      在前一篇博客（見LTE：上行調(diào)度請求（Scheduling Request，SR）中已經(jīng)介紹到，UE通過SR向eNodeB請求上行資源時，只指明了其是否有上行數(shù)據(jù)需要發(fā)送，而沒有指明自己需要發(fā)送多少上行數(shù)據(jù)。UE需要通過BSR（Buffer Status Report）告訴eNodeB，其上行buffer里有多少數(shù)據(jù)需要發(fā)送，以便eNodeB

36、決定給該UE分配多少上行資源。      根據(jù)業(yè)務(wù)的不同，UE可能建立大量的無線承載（radio bearer，每個bearer對應(yīng)一個邏輯信道），如果為每一個邏輯信道上報一個BSR，會帶來大量的信令開銷。為了避免這種開銷，LTE引入了LCG（Logical Channel Group）的概念，并將每個邏輯信道放入一個LCG（共4個）中。UE基于LCG來上報BSR，而不是為每個邏輯信道上報一個BSR。      某個邏輯信道所屬的LCG是在邏輯信道建立時通過IE: LogicalChannelC

37、onfig 的logicalChannelGroup字段來設(shè)置的 。  LogicalChannelConfig :=         SEQUENCE     ul-SpecificParameters            SEQUENCE        priority  

38、                       INTEGER (1.16),       prioritisedBitRate               ENUMERATED &

39、#160;                                           kBps0, kBps8, kBps16, kBps32, kBps64, kBps

40、128,                                            kBps256, infinity, kBps512-v1020, kBp

41、s1024-v1020,                                            kBps2048-v1020, spare5, spare

42、4, spare3, spare2,                                            spare1,  

43、0;    bucketSizeDuration               ENUMERATED                            

44、60;                ms50, ms100, ms150, ms300, ms500, ms1000, spare2,                          &

45、#160;                 spare1,       logicalChannelGroup                  INTEGER (0.3)    

46、    OPTIONAL          - Need OR          OPTIONAL,                         

47、                                   - Cond UL    .,      logicalChannelSR-Mask-r9  

48、60;      ENUMERATED setup    OPTIONAL       - Cond SRmask            將邏輯信道分組是為了提供更好的BSR上報機制。將那些有相似調(diào)度需求的邏輯信道放入同一LCG中，并通過short BSR上報其buffer狀態(tài)。      如何分組取決于eNodeB的算法實現(xiàn)（

49、例如：將相同QCI/priority的邏輯信道放入同一LCG中）。即上行的QoS管理是由eNodeB負責管理的。      由于UE的LCG和邏輯信道的配置是由eNodeB控制的，所以eNodeB知道每個LCG包含哪些邏輯信道以及這些邏輯信道的優(yōu)先級。雖然eNodeB無法知道一個單獨的邏輯信道的buffer狀態(tài)，但由于同一LCG中的邏輯信道有著類似的QoS/priority需求，所以基于LCG來上報buffer狀態(tài)也可以使得上行調(diào)度提供合適的調(diào)度結(jié)果。 一、BSR MAC Control Element  

50、0;   BSR通過MAC層的BSR MAC Control  Element上報，包含2種格式：·        Short BSR或Truncated BSR格式：只上報一個LCG的BSR。其格式由一個LCG ID域和一個對應(yīng)的Buffer Size域組成。如圖1所示 圖1：Short BSR和Truncated BSR MAC control element ·        Lo

51、ng BSR格式：包含了4個Buffer Size域，對應(yīng)LCG ID 03。該格式會將所有LCG的Buffer Size一起上報給eNodeB。如圖2所示 圖2：Long BSR MAC control element       LCG ID域長為2 bit，指定了上報的buffer狀態(tài)對應(yīng)的LCG，其值與IE: LogicalChannelConfig 的logicalChannelGroup字段對應(yīng)。      Buffer Size域長為6 bit，指定了UE在發(fā)送這個BSR

52、的TTI內(nèi)的所有MAC PDU都生成以后，對應(yīng)LCG的所有邏輯信道的RLC層和PDCP層中剩余的可用于傳輸?shù)挠行?shù)據(jù)的總和（見36.322的4.5節(jié)和36.323的4.5節(jié)）。該數(shù)據(jù)量以byte為單位，但不將RLC頭部和MAC頭部信息計算在內(nèi)。      從36.321的6.1.3.1節(jié)可以看出，eNodeB收到BSR后，通過Buffer Size域得到一個index，再用這個index查Table 6.1.3.1-1或Table 6.1.3.1-2，可以得到UE真正需要發(fā)送的“近似”上行數(shù)據(jù)量。因為UE在發(fā)送BSR時，無法確定后續(xù)發(fā)送的上行數(shù)

53、據(jù)中會有哪些RLC頭部和MAC頭部，所以計算時不將RLC頭部和MAC頭部信息計算在內(nèi)。而從Table 6.1.3.1-1和Table 6.1.3.1-2可以看出，通過Buffer Size域得到的index對應(yīng)的是一個Buffer Size的范圍，而不是一個精確的Buffer Size，因此是一個“近似”上行數(shù)據(jù)量。        在載波聚合中，可能存在多個上行載波單元同時發(fā)送數(shù)據(jù)，BSR指示的數(shù)據(jù)量也可能遠大于Rel-8中指示的數(shù)據(jù)量，因此在Rel-10中，LTE額外提供了一個BSR值的表（見36.321的Table 6.

54、1.3.1-2）。具體使用Table 6.1.3.1-1還是Table 6.1.3.1-2是通過IE：MAC-MainConfig的extendedBSR-Sizes-r10字段來配置的。       一個BSR MAC control element與一個MAC subheader對應(yīng)。BSR對應(yīng)的MAC subheader中的LCID域如圖3所示：（見36.321的Table 6.2.1-2） 圖3：UL-SCH的所有LCID值       注意：LCID與LCG ID是

55、不同的。LCID是用來唯一地指定MAC PDU中的一個MAC SDU或MAC control element或padding的。而LCG ID是用來指定邏輯信道所屬的邏輯信道組ID的，只用于BSR上報。 二、BSR的觸發(fā)方式      當如下事件發(fā)生時，將會觸發(fā)BSR上報：      1、UE的上行數(shù)據(jù)buffer為空且有新數(shù)據(jù)到達：當所有LCG的所有邏輯信道都沒有可發(fā)送的上行數(shù)據(jù)時，如果此時屬于任意一個LCG的任意一個邏輯信道有數(shù)據(jù)變得可以發(fā)送，則UE會觸發(fā)BSR上報。例如：UE第一

56、次發(fā)送上行數(shù)據(jù)。該BSR被稱為“Regular BSR”;      2、高優(yōu)先級的數(shù)據(jù)到達：如果UE已經(jīng)發(fā)送了一個BSR，并且正在等待UL grant，此時有更高優(yōu)先級的數(shù)據(jù)（即該數(shù)據(jù)所屬的邏輯信道【而不是LCG】比任意一個LCG的邏輯信道的優(yōu)先級都要高）需要傳輸，則UE會觸發(fā)BSR上報。該BSR被稱為“Regular BSR”；      3、UE周期性地向eNodeB更新自己的buffer狀態(tài)：eNodeB通過IE：MAC-MainConfig的periodicBSR-Timer字段為UE配置了一個timer

57、（配置成”infinity”則去使能該timer），如果該timer超時，UE會觸發(fā)BSR上報。例如：當UE需要上傳一個大文件時，數(shù)據(jù)到達UE傳輸buffer的時間與UE收到UL grant的時間是不同步的，也就是說UE在發(fā)送BSR和接收UL grant的同時，還在不停地往上行傳輸buffer里填數(shù)據(jù)，因此UE需要不停地更新需要傳輸?shù)纳闲袛?shù)據(jù)量。該BSR被稱為“Periodic BSR”；      4、為提高BSR的健壯性，LTE提供了一個重傳BSR的機制：這是為了避免UE發(fā)送了BSR卻一直沒有收到UL grant的情況。eNodeB通過IE：MAC-MainC

58、onfig的retxBSR-Timer字段為UE配置了一個timer，當該timer超時且UE的任意一個LCG的任意一個邏輯信道里有數(shù)據(jù)可以發(fā)送時，將會觸發(fā)BSR。該BSR被稱為“Regular BSR”。      5、廢物再利用：當UE有上行資源且發(fā)現(xiàn)需要發(fā)送的數(shù)據(jù)不足以填滿該資源時，多余出來的bit會作為Padding bit而被填充一些無關(guān)緊要的值。與其用作padding bit，還不如用來傳BSR這些有用的數(shù)據(jù)。所以當padding bit的數(shù)量等于或大于“BSR MAC control element + 對應(yīng)的subheader”

59、的大小時，UE會使用這些bit來發(fā)送BSR。該BSR被稱為“Padding BSR”。      從上面的介紹可以看出，只有當某個邏輯信道屬于某個LCG時，它的數(shù)據(jù)才會被統(tǒng)計到對應(yīng)的BSR中并上報給eNodeB；對于不屬于任一LCG的邏輯信道（logicalChannelGroup字段是OPTIONAL的），其數(shù)據(jù)不會被統(tǒng)計，不會影響任何BSR行為。      如果至少觸發(fā)了一個BSR且該BSR沒有被取消且UE已經(jīng)在該TTI內(nèi)收到了用于新傳數(shù)據(jù)的UL grant，則UE會· 

60、       生成BSR MAC control element；·        除非所有生成的BSR均為Truncated BSR，否則UE會啟動或重啟periodicBSR-Timer；·        啟動或重啟retxBSR-Timer；       當觸發(fā)了Regular BSR，但UE沒有足夠的UL-SCH資源用于發(fā)送BSR時，UE會發(fā)送SR請求；而當觸發(fā)了Periodic BSR或Padding BSR，但UE沒有足夠的UL-SCH資源