LTE學(xué)習(xí)筆記HARQ、BSR_第1頁(yè)
LTE學(xué)習(xí)筆記HARQ、BSR_第2頁(yè)
LTE學(xué)習(xí)筆記HARQ、BSR_第3頁(yè)
LTE學(xué)習(xí)筆記HARQ、BSR_第4頁(yè)
LTE學(xué)習(xí)筆記HARQ、BSR_第5頁(yè)
已閱讀5頁(yè),還剩13頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

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資源

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論