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

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

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

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

5、-2（見下圖）。（見36.213的8.0節）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與對應的PUSCH傳輸之間的timing關系。以TDD Configuration 1為例，如果UE在子幀1收到了UL grant（或PHICH），則UE會在子幀7（n+k=1+6）發送PUSCH（或重傳）；如果UE在子幀9收到了UL grant（或PH

7、ICH），則UE會在下一系統幀的子幀3（n+k=9+4）發送PUSCH（或重傳）。圖4：TDD 1/2中，UL grant/PHICH與對應的PUSCH傳輸之間的timing關系（對應36.213的Table 8-2）      對TDD UL/DL configuration 1-6而言，如果UE在子幀n收到了PHICH，則該PHICH對應UE在上行子幀n - k發送的PUSCH。其中k的值見36.213的Table 8.3-1（見下圖）。（見36.213的8.3節）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傳輸與對應的PHICH（ACK/NACK）之間的timing關系。以TDD Configuration 1為例，如果UE在子幀2發送了PUSCH，則UE會在子幀6（N-K=6-4）接收對應的PHICH；如果UE在子幀7發送了PUSCH，則UE會在下一系統幀的子幀1（N-K=1-4=7）接收對應的PHICH。 圖5：TDD 1/2中，PUSCH傳輸與對應的PHIC

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

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

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

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

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

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

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

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

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

19、傳，則UE不僅會收到PHICH，還會收到PDCCH（UL grant）。如果需要重傳，UE會根據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是預留的，不攜帶真正的MCS信息，因此如果MCS index為2931，其MCS遵循前一次傳輸使用的MCS（TB size

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

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

22、RQ bundling和HARQ multiplexing 對于TDD，如果UE不支持聚合超過1個serving cell，即非載波聚合的條件下，RRC層可以給UE配置2種ACK/NACK反饋模式。（見36.213的10.1.3節）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的多個下行子幀的對應同一codeword的ACK/NACK做邏輯與（logical AND

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

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

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

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

28、理）使用HARQ bundling的場景有3種（見36.213的7.3節）：      （1）tdd-AckNackFeedbackMode設置為bundling；      （2）tdd-AckNackFeedbackMode設置為multiplexing，但回應ACK/NACK的上行子幀對應的M值為1（M的取值見36.213的Table 10.1.3.1-1），即一個上行子幀對應一個下行子幀的場景。這種場景至多需要回應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節）對于HARQ bundling，當UE配置了TM 3/4/8/9并且ACK/NACK在PUSCH上傳輸（注意：不包含PUCCH上回應ACK/NACK的情況），則UE總是假定

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

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

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

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

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

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

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

37、onfig 的logicalChannelGroup字段來設置的 。  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上報機制。將那些有相似調度需求的邏輯信道放入同一LCG中，并通過short BSR上報其buffer狀態。      如何分組取決于eNodeB的算法實現（

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

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

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

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

53、據中會有哪些RLC頭部和MAC頭部，所以計算時不將RLC頭部和MAC頭部信息計算在內。而從Table 6.1.3.1-1和Table 6.1.3.1-2可以看出，通過Buffer Size域得到的index對應的是一個Buffer Size的范圍，而不是一個精確的Buffer Size，因此是一個“近似”上行數據量。        在載波聚合中，可能存在多個上行載波單元同時發送數據，BSR指示的數據量也可能遠大于Rel-8中指示的數據量，因此在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對應。BSR對應的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的觸發方式      當如下事件發生時，將會觸發BSR上報：      1、UE的上行數據buffer為空且有新數據到達：當所有LCG的所有邏輯信道都沒有可發送的上行數據時，如果此時屬于任意一個LCG的任意一個邏輯信道有數據變得可以發送，則UE會觸發BSR上報。例如：UE第一

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

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

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

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

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