LTE上行定時技術(shù)(共11頁)_第1頁
LTE上行定時技術(shù)(共11頁)_第2頁
LTE上行定時技術(shù)(共11頁)_第3頁
LTE上行定時技術(shù)(共11頁)_第4頁
LTE上行定時技術(shù)(共11頁)_第5頁
已閱讀5頁,還剩6頁未讀, 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

1、精選優(yōu)質(zhì)文檔-傾情為你奉上上行定時提前(Uplink Timing Advance)       本文將介紹LTE中的上行同步過程。主要涉及:1)為何需要上行同步;2)eNodeB如何測量上行定時提前量并下發(fā)Timing Advance Command;3)eNodeB和UE如何判斷上行失步(eNodeB側(cè)只會做一些原理性的介紹,不同廠家的實現(xiàn)可能不同)。       上行傳輸?shù)囊粋€重要特征是不同UE在時頻上正交多址接入(orthogonal multiple access),即來自同

2、一小區(qū)的不同UE的上行傳輸之間互不干擾。      為了保證上行傳輸?shù)恼恍裕苊庑^(qū)內(nèi)(intra-cell)干擾,eNodeB要求來自同一子幀但不同頻域資源(不同的RB)的不同UE的信號到達(dá)eNodeB的時間基本上是對齊的。eNodeB只要在CP(Cyclic Prefix)范圍內(nèi)接收到UE所發(fā)送的上行數(shù)據(jù),就能夠正確地解碼上行數(shù)據(jù),因此上行同步要求來自同一子幀的不同UE的信號到達(dá)eNodeB的時間都落在CP之內(nèi)。      為了保證接收側(cè)(eNodeB側(cè))的時間同步,LTE提出了上行定時提

3、前(Uplink Timing Advance)的機制。      在UE側(cè)看來,timing advance本質(zhì)上是接收到下行子幀的起始時間與傳輸上行子幀的時間之間的一個負(fù)偏移(negative offset)。eNodeB通過適當(dāng)?shù)乜刂泼總€UE的偏移,可以控制來自不同UE的上行信號到達(dá)eNodeB的時間。對于離eNodeB較遠(yuǎn)的UE,由于有較大的傳輸延遲,就要比離eNodeB較近的UE提前發(fā)送上行數(shù)據(jù)。  圖1:上行傳輸?shù)膖iming對齊       圖1的(a

4、)中指出了不進(jìn)行上行定時提前所造成的影響。      從圖1的(b)中可以看出,eNodeB側(cè)的上行子幀和下行子幀的timing是相同的,而UE側(cè)的上行子幀和下行子幀的timing之間有偏移。      同時可以看出:不同UE有各自不同的uplink timing advance,也即unlink timing advance是UE級的配置。       前面介紹了為什么需要做uplink timing advance,接下來我們來介紹

5、eNodeB如何測量上行信號以得到每個UE的上行定時提前量以及如何下發(fā)Timing Advance Command給UE。      eNodeB通過兩種方式給UE發(fā)送Timing Advance Command:      1)在隨機接入過程,eNodeB通過測量接收到preamble來確定timing advance值,并通過RAR的Timing Advance Command字段(共11 bit,對應(yīng)TA索引值的范圍是01282)發(fā)送給UE。 圖2:MAC RAR &#

6、160;     上行同步的粒度為(0.52 ms)。對于隨機接入而言,值乘以,就得到相對于當(dāng)前上行timing所需的實際調(diào)整值(單位為)。關(guān)于,見36.211的第4章。      上行timing的不確定性正比于小區(qū)半徑,每1 km有大約6.7s的傳輸延遲(6.7s / km),LTE中小區(qū)最大半徑為100 km,故最大傳輸延遲接近0.67 ms。上行同步的粒度為(0.52 ms),故的最大值約為(0.67 * 1000)/0.52 1288。(的最大值為1282,應(yīng)該是更精確的計算,但計算方法就是這樣

7、的,當(dāng)然還要將解碼時間考慮在內(nèi))      我稱這個過程為“初始上行同步過程”。       2)在RRC_CONNECTED態(tài),eNodeB需要維護(hù)timing advance信息。      雖然在隨機接入過程中,UE與eNodeB取得了上行同步,但上行信號到達(dá)eNodeB的timing可能會隨著時間發(fā)生變化:·        高速移動中的UE,例如運行

8、中的高鐵上的UE,其與eNodeB的傳輸延遲會不斷變化;·        當(dāng)前傳輸路徑消失,切換到新的的傳輸路徑。例如在建筑物密集的城市,走到建筑的轉(zhuǎn)角時,這種情況就很可能發(fā)生;·        UE的晶振偏移,長時間的偏移累積可能導(dǎo)致上行定時出錯;·        由于UE移動而導(dǎo)致的多普勒頻移等。      因此,

9、UE需要不斷地更新其上行定時提前量,以保持上行同步。LTE中,eNodeB使用一種閉環(huán)機制來調(diào)整上行定時提前量。      eNodeB基于測量對應(yīng)UE的上行傳輸來確定每個UE的timing advance值。因此,只要UE有上行傳輸, eNodeB就可以用來估計timing advance值。理論上,UE發(fā)送的任何信號(SRS/DMRS/CQI/ACK/NACK/PUSCH等)都可用于測量timing advance。      如果某個特定UE需要校正,則eNodeB會發(fā)送一個Timing&

10、#160; Advance Command 給該UE,要求其調(diào)整上行傳輸timing。該Timing  Advance Command 是通過Timing  Advance Command  MAC control element發(fā)送給UE的。      Timing  Advance Command  MAC control element由LCID值為11101(見36.321的Table 6.2.1-1)的MAC PDU subhead指示,且其結(jié)構(gòu)如下(R表示預(yù)留bit,設(shè)為0):

11、60; 圖3:Timing Advance Command MAC control element       可以看出,Timing Advance Command字段共6 bit,對應(yīng)TA索引值的范圍是063。      UE側(cè)會保存最近一次timing advance調(diào)整值,當(dāng)UE收到新的Timing Advance Command而得到后,會計算出最新的timing advance調(diào)整值(單位為)。      我稱這個

12、過程為“上行同步更新過程”。如果UE在子幀n收到Timing Advance Command,則UE會從子幀n + 6開始應(yīng)用該timing調(diào)整值。      如果UE在子幀n和子幀n + 1發(fā)送的PUCCH/PUSCH/SRS由于timing調(diào)整的原因出現(xiàn)重疊,則UE將完全發(fā)送子幀n的內(nèi)容,而不發(fā)送子幀n + 1中重疊的部分。      UE收到Timing Advance Command后,會調(diào)整PCell的PUCCH/PUSCH/SRS的上行發(fā)送時間。而SCell的PUSCH/SRS(SC

13、ell不發(fā)送PUCCH)的上行發(fā)送時間調(diào)整量與PCell相同。(見36.213的4.2.3節(jié))      從上面的介紹可以看出,PCell和SCell共用一條Timing Advance Command在載波聚合中,UE可能需要往多個小區(qū)(或稱為component carrier)發(fā)送上行數(shù)據(jù),在理論上,由于不同小區(qū)的物理位置(inter-band CA)可能不同,每個小區(qū)都需要給該UE發(fā)送各自的Timing Advance Command。但是這種類型的部署并不常見,載波聚合的小區(qū)通常物理位置上相近且同步,因此為了簡化LTE的設(shè)計,所有聚合的

14、小區(qū)共用一條timing advance command。       前面已經(jīng)介紹過,上行定時提前的調(diào)整量是相對于接收到的下行子幀的timing的,因此在UE沒有收到Timing Advance Command的時候,UE需要跟蹤下行timing的變化,以便自動調(diào)整上行傳輸?shù)膖iming。(詳見36.133的7.1.2節(jié))       接下來,我們介紹UE在MAC層如何判斷上行同步/失步(詳見36.321的5.2節(jié)):    

15、0; eNodeB會通過RRC信令給UE配置一個timer(在MAC層,稱為timeAlignmentTimer),UE使用該timier在MAC層確定上行是否同步。      需要注意的是:該timer有Cell-specific級別和UE-specific級別之分。eNodeB通過SystemInformationBlockType2的timeAlignmentTimerCommon字段來配置的Cell-specific級別的timer;eNodeB通過MAC-MainConfig的timeAlignmentTimerDedicated字段

16、來配置UE-specific級別的timer。      如果UE配置了UE-specific的timer,則UE使用該timer值,否則UE使用Cell-specific的timer值。      當(dāng)UE收到Timing Advance Command(來自RAR或Timing Advance Command MAC control element),UE會啟動或重啟該timer。如果該timer超時,則認(rèn)為上行失步,UE會清空HARQ buffer,通知RRC層釋放PUCCH/SRS,并清空

17、任何配置的DL assignment和UL grant。      當(dāng)該timer在運行時,UE認(rèn)為上行是同步的;而當(dāng)該timer沒有運行,即上行失步時,UE在上行只能發(fā)送preamble。      還有一種情況下,UE認(rèn)為上行同步狀態(tài)由“同步”變?yōu)椤安煌健保悍峭紿andover。       最后,我們介紹eNodeB是如何處理UE的上行同步呢?由于不同的廠商實現(xiàn)方式可能不同,這里只介紹一些可借鑒的做法。  

18、    (1)由于UE必須在timeAlignmentTimer超時之前接收到Timing Advance Command,否則會認(rèn)為上行失步。所以eNodeB需要保證在該timer時間范圍內(nèi)(通常要比該timer小,因為要預(yù)留一些時間給傳輸延遲和UE編解碼等)給UE發(fā)送Timing Advance Command,以便UE更新上行定時并重啟該timer。所以eNodeB必須保存最近一次成功地給該UE發(fā)送了Timing Advance Command(即eNodeB收到了對應(yīng)下行傳輸?shù)腁CK)的子幀號,以便計算該時間范圍。   

19、60;  (2)從(1)中可以看出,在eNodeB側(cè)在MAC層也應(yīng)該為每個UE維護(hù)一個類似timeAlignmentTimer的timer,以保證在該timer超時之前給UE發(fā)送Timing Advance Command。eNodeB何時啟動/重啟該timer呢?個人認(rèn)為可以在UE隨機接入成功中后啟動,并在收到對應(yīng)Timing Advance Command MAC control element的ACK/NACK后重啟。注意timer的起始位置應(yīng)該從最近一次成功地給該UE發(fā)送了Timing Advance Command的子幀(而不是收到對應(yīng)ACK的子幀)。  

20、;    (3)從上面的介紹可以看出, UE在子幀n收到Timing Advance Command后,會從子幀n + 6才開始應(yīng)用該timing調(diào)整值。也就是說,eNodeB在子幀n發(fā)送了某個UE的Timing Advance Command之后,在子幀n + 6之前(不包括n + 6子幀)的時間內(nèi),是不會去測量該UE的上行timing的。      (4)在子幀n + 6之后,eNodeB可能需要測量多個上行timing瞬時值以作平均處理,以便得到最終的調(diào)整量,也就是說,eNodeB可能在n + 6子幀后的某段時間內(nèi),是不會發(fā)送Timing Advance Command的。當(dāng)測量完畢后,eNodeB在之后的某個子幀將Timing  Advance Command  MAC con

溫馨提示

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

評論

0/150

提交評論