LTE學(xué)習(xí)筆記HARQ、BSR

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

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

3、適應(yīng)重傳），則UE會(huì)在n + 4子幀發(fā)送對(duì)應(yīng)的PUSCH。（見36.213的8.0節(jié)）      對(duì)FDD而言，如果UE在子幀n收到了PHICH，則該P(yáng)HICH對(duì)應(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都對(duì)應(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)系略有不同。（注：每個(gè)子幀只對(duì)應(yīng)一個(gè)HARQ process，空分復(fù)用的情況下是2個(gè)，每個(gè)對(duì)應(yīng)一個(gè)TB。）2) TDD 16      對(duì)TDD UL/DL configuration 16而言，如果UE在子幀n收到了UL grant（DCI format 0/4，對(duì)應(yīng)新傳或自適應(yīng)重傳）或PHICH（只收到NACK，對(duì)應(yīng)非自適應(yīng)重傳），則UE會(huì)在n + k子幀發(fā)送對(duì)應(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與對(duì)應(yīng)的PUSCH傳輸之間的timing關(guān)系。以TDD Configuration 1為例，如果UE在子幀1收到了UL grant（或PHICH），則UE會(huì)在子幀7（n+k=1+6）發(fā)送PUSCH（或重傳）；如果UE在子幀9收到了UL grant（或PH

7、ICH），則UE會(huì)在下一系統(tǒng)幀的子幀3（n+k=9+4）發(fā)送PUSCH（或重傳）。圖4：TDD 1/2中，UL grant/PHICH與對(duì)應(yīng)的PUSCH傳輸之間的timing關(guān)系（對(duì)應(yīng)36.213的Table 8-2）      對(duì)TDD UL/DL configuration 1-6而言，如果UE在子幀n收到了PHICH，則該P(yáng)HICH對(duì)應(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傳輸與對(duì)應(yīng)的PHICH（ACK/NACK）之間的timing關(guān)系。以TDD Configuration 1為例，如果UE在子幀2發(fā)送了PUSCH，則UE會(huì)在子幀6（N-K=6-4）接收對(duì)應(yīng)的PHICH；如果UE在子幀7發(fā)送了PUSCH，則UE會(huì)在下一系統(tǒng)幀的子幀1（N-K=1-4=7）接收對(duì)應(yīng)的PHICH。 圖5：TDD 1/2中，PUSCH傳輸與對(duì)應(yīng)的PHIC

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

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

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

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

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

15、CH對(duì)應(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傳輸與對(duì)應(yīng)的ACK/NACK之間的timing關(guān)系【舉例】      圖9是一個(gè)FDD下，上行HARQ的例子。TDD除了timing關(guān)系不同外，其它處理是一樣的。圖不是很清晰，大家注意一下每個(gè)子幀對(duì)應(yīng)的虛線。圖9：非自適應(yīng)和自適應(yīng)HARQ操作（FDD）      注：R-10中新增了DCI format 4以支持上行空

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

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

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

19、傳，則UE不僅會(huì)收到PHICH，還會(huì)收到PDCCH（UL grant）。如果需要重傳，UE會(huì)根據(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個(gè)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在時(shí)域上的同步關(guān)系。每種配置都包含2部分：1）UL grant/PHICH與對(duì)應(yīng)的PUSCH傳輸之間的timing關(guān)系；2）PUSCH傳輸與對(duì)應(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只會(huì)收到PHICH中指示的ACK/NACK信息。如果是自適應(yīng)重傳，則UE不僅會(huì)收到PHICH，還會(huì)收到PDCCH（UL grant）。2、 在非自適應(yīng)重傳時(shí)，重傳與與前一次傳輸使用相同的PRB資源和MCS。因此下行只需要PHICH這一種控制信令，而不需要PDCCH（UL grant），從而降低了開銷。在自適應(yīng)重傳時(shí)是為了避免分割上行頻域資源或避免與隨機(jī)接入的資源發(fā)生碰撞。此時(shí)eNodeB不僅會(huì)發(fā)送PHICH，還會(huì)發(fā)送PDCCH（UL grant）以指示重傳所使用的新的PRB資源和MCS。3、 自適應(yīng)重傳/非自適應(yīng)重傳的同步timing時(shí)間不一樣。二、HA

22、RQ bundling和HARQ multiplexing 對(duì)于TDD，如果UE不支持聚合超過1個(gè)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字段來配置的。該字段對(duì)PUCCH和PUSCH上回復(fù)的ACK/NACK均有效。一、HARQ bundling      HARQ bundling：將同一serving cell的多個(gè)下行子幀的對(duì)應(yīng)同一codeword的ACK/NACK做邏輯與（logical AND

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

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

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

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

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

29、exing，至多只能攜帶1 bit的信息，反而不如使用HARQ bundling將2 bit的信息都回復(fù)給eNodeB（使用PUCCH format 1b）。      （3）對(duì)于TDD UL-DL configuration 5且UE不支持聚合超過1個(gè)serving cell（即非載波聚合條件下），則該UE只支持HARQ bundling。（見36.213的10.1.3節(jié)）對(duì)于HARQ bundling，當(dāng)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檢測(cè)到PDSCH傳輸，則UE為codeword 1生成NACK。（關(guān)于codeword使能/去使能，會(huì)在后面介紹）      通過之前的介紹，我們可以看出，對(duì)于HARQ bundling，只要UE在綁定窗口內(nèi)有一個(gè)TB沒有正確接收（NACK/DTX），對(duì)應(yīng)該TB所在的codeword，eNodeB就應(yīng)該收到NACK或根本沒收到HARQ反饋，并重傳所有下行子幀對(duì)應(yīng)該codeword的數(shù)據(jù)。  

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

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

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

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

35、則該UE只支持HARQ bundling，而不支持HARQ multiplexing。（見36.213的10.1.3節(jié)）總結(jié)：參考二、Buffer Status Report（BSR）      在前一篇博客（見LTE：上行調(diào)度請(qǐng)求（Scheduling Request，SR）中已經(jīng)介紹到，UE通過SR向eNodeB請(qǐng)求上行資源時(shí)，只指明了其是否有上行數(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，每個(gè)bearer對(duì)應(yīng)一個(gè)邏輯信道），如果為每一個(gè)邏輯信道上報(bào)一個(gè)BSR，會(huì)帶來大量的信令開銷。為了避免這種開銷，LTE引入了LCG（Logical Channel Group）的概念，并將每個(gè)邏輯信道放入一個(gè)LCG（共4個(gè)）中。UE基于LCG來上報(bào)BSR，而不是為每個(gè)邏輯信道上報(bào)一個(gè)BSR。      某個(gè)邏輯信道所屬的LCG是在邏輯信道建立時(shí)通過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上報(bào)機(jī)制。將那些有相似調(diào)度需求的邏輯信道放入同一LCG中，并通過short BSR上報(bào)其buffer狀態(tài)。      如何分組取決于eNodeB的算法實(shí)現(xiàn)（

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

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

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

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

53、據(jù)中會(huì)有哪些RLC頭部和MAC頭部，所以計(jì)算時(shí)不將RLC頭部和MAC頭部信息計(jì)算在內(nèi)。而從Table 6.1.3.1-1和Table 6.1.3.1-2可以看出，通過Buffer Size域得到的index對(duì)應(yīng)的是一個(gè)Buffer Size的范圍，而不是一個(gè)精確的Buffer Size，因此是一個(gè)“近似”上行數(shù)據(jù)量。        在載波聚合中，可能存在多個(gè)上行載波單元同時(shí)發(fā)送數(shù)據(jù)，BSR指示的數(shù)據(jù)量也可能遠(yuǎn)大于Rel-8中指示的數(shù)據(jù)量，因此在Rel-10中，LTE額外提供了一個(gè)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字段來配置的。       一個(gè)BSR MAC control element與一個(gè)MAC subheader對(duì)應(yīng)。BSR對(duì)應(yīng)的MAC subheader中的LCID域如圖3所示：（見36.321的Table 6.2.1-2） 圖3：UL-SCH的所有LCID值       注意：LCID與LCG ID是

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

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

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

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

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

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