LTE上行定時技術(shù)

上行定時提前〔UplinkTimingAdvance〕本文將介紹LTE中的上行同步過程。主要涉及：1〕為何需要上行同步；2〕eNodeB如何測量上行定時提前量并下發(fā)TimingAdvanceCommand；3〕eNodeB和UE如何判斷上行失步〔eNodeB側(cè)只會做一些原理性的介紹，不同廠家的實現(xiàn)可能不同〕。上行傳輸?shù)囊粋€重要特征是不同UE在時頻上正交多址接入〔orthogonalmultipleaccess〕，即來自同一小區(qū)的不同UE的上行傳輸之間互不干擾。為了保證上行傳輸?shù)恼恍?，防止小區(qū)內(nèi)〔intra-cell〕干擾，eNodeB要求來自同一子幀但不同頻域資源〔不同的RB〕的不同UE的信號到達eNodeB的時間根本上是對齊的。eNodeB只要在CP〔CyclicPrefix〕范圍內(nèi)接收到UE所發(fā)送的上行數(shù)據(jù)，就能夠正確地解碼上行數(shù)據(jù)，因此上行同步要求來自同一子幀的不同UE的信號到達eNodeB的時間都落在CP之內(nèi)。為了保證接收側(cè)〔eNodeB側(cè)〕的時間同步，LTE提出了上行定時提前〔UplinkTimingAdvance〕的機制。在UE側(cè)看來，timingadvance本質(zhì)上是接收到下行子幀的起始時間與傳輸上行子幀的時間之間的一個負偏移〔negativeoffset〕。eNodeB通過適當?shù)乜刂泼總€UE的偏移，可以控制來自不同UE的上行信號到達eNodeB的時間。對于離eNodeB較遠的UE，由于有較大的傳輸延遲，就要比離eNodeB較近的UE提前發(fā)送上行數(shù)據(jù)。圖1：上行傳輸?shù)膖iming對齊圖1的(a)中指出了不進行上行定時提前所造成的影響。從圖1的(b)中可以看出，eNodeB側(cè)的上行子幀和下行子幀的timing是相同的，而UE側(cè)的上行子幀和下行子幀的timing之間有偏移。同時可以看出：不同UE有各自不同的uplinktimingadvance，也即unlinktimingadvance是UE級的配置。前面介紹了為什么需要做uplinktimingadvance，接下來我們來介紹eNodeB如何測量上行信號以得到每個UE的上行定時提前量以及如何下發(fā)TimingAdvanceCommand給UE。

eNodeB通過兩種方式給UE發(fā)送TimingAdvanceCommand：

1〕在隨機接入過程，eNodeB通過測量接收到preamble來確定timingadvance值，并通過RAR的TimingAdvanceCommand字段〔共11bit，對應(yīng)TA索引值的范圍是0~1282〕發(fā)送給UE。圖2：MACRAR上行同步的粒度為〔0.52s〕。對于隨機接入而言，值乘以，就得到相對于當前上行timing所需的實際調(diào)整值〔單位為〕。關(guān)于，見36.211的第4章。上行timing的不確定性正比于小區(qū)半徑，每1km有大約6.7μs的傳輸延遲〔6.7μs/km〕，LTE中小區(qū)最大半徑為100km，故最大傳輸延遲接近0.67ms。上行同步的粒度為〔0.52s〕，故的最大值約為(0.67*1000)/0.52≈1288?！驳淖畲笾禐?282，應(yīng)該是更精確的計算，但計算方法就是這樣的，當然還要將解碼時間考慮在內(nèi)〕我稱這個過程為“初始上行同步過程〞。

2〕在RRC_CONNECTED態(tài)，eNodeB需要維護timingadvance信息。雖然在隨機接入過程中，UE與eNodeB取得了上行同步，但上行信號到達eNodeB的timing可能會隨著時間發(fā)生變化：高速移動中的UE，例如運行中的高鐵上的UE，其與eNodeB的傳輸延遲會不斷變化；當前傳輸路徑消失，切換到新的的傳輸路徑。例如在建筑物密集的城市，走到建筑的轉(zhuǎn)角時，這種情況就很可能發(fā)生；UE的晶振偏移，長時間的偏移累積可能導(dǎo)致上行定時出錯；由于UE移動而導(dǎo)致的多普勒頻移等。因此，UE需要不斷地更新其上行定時提前量，以保持上行同步。LTE中，eNodeB使用一種閉環(huán)機制來調(diào)整上行定時提前量。

eNodeB基于測量對應(yīng)UE的上行傳輸來確定每個UE的timingadvance值。因此，只要UE有上行傳輸，eNodeB就可以用來估計timingadvance值。理論上，UE發(fā)送的任何信號〔SRS/DMRS/CQI/ACK/NACK/PUSCH等〕都可用于測量timingadvance。如果某個特定UE需要校正，那么eNodeB會發(fā)送一個Timing

AdvanceCommand給該UE，要求其調(diào)整上行傳輸timing。該Timing

AdvanceCommand是通過Timing

AdvanceCommand

MACcontrolelement發(fā)送給UE的。

Timing

AdvanceCommand

MACcontrolelement由LCID值為11101〔見36.321的〕的MACPDUsubhead指示，且其結(jié)構(gòu)如下〔R表示預(yù)留bit，設(shè)為0〕：圖3：TimingAdvanceCommandMACcontrolelement可以看出，TimingAdvanceCommand字段共6bit，對應(yīng)TA索引值的范圍是0~63。

UE側(cè)會保存最近一次timingadvance調(diào)整值，當UE收到新的TimingAdvanceCommand而得到后，會計算出最新的timingadvance調(diào)整值〔單位為〕。我稱這個過程為“上行同步更新過程〞。如果UE在子幀n收到TimingAdvanceCommand，那么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收到TimingAdvanceCommand后，會調(diào)整PCell的PUCCH/PUSCH/SRS的上行發(fā)送時間。而SCell的PUSCH/SRS〔SCell不發(fā)送PUCCH〕的上行發(fā)送時間調(diào)整量與PCell相同?！惨?6.213的節(jié)〕從上面的介紹可以看出，PCell和SCell共用一條TimingAdvanceCommand在載波聚合中，UE可能需要往多個小區(qū)〔或稱為componentcarrier〕發(fā)送上行數(shù)據(jù)，在理論上，由于不同小區(qū)的物理位置〔inter-bandCA〕可能不同，每個小區(qū)都需要給該UE發(fā)送各自的TimingAdvanceCommand。但是這種類型的部署并不常見，載波聚合的小區(qū)通常物理位置上相近且同步，因此為了簡化LTE的設(shè)計，所有聚合的小區(qū)共用一條timingadvancecommand。前面已經(jīng)介紹過，上行定時提前的調(diào)整量是相對于接收到的下行子幀的timing的，因此在UE沒有收到TimingAdvanceCommand的時候，UE需要跟蹤下行timing的變化，以便自動調(diào)整上行傳輸?shù)膖iming?！苍斠?6.133的節(jié)〕接下來，我們介紹UE在MAC層如何判斷上行同步/失步〔詳見36.321的5.2節(jié)〕：

eNodeB會通過RRC信令給UE配置一個timer〔在MAC層，稱為timeAlignmentTimer〕，UE使用該timier在MAC層確定上行是否同步。需要注意的是：該timer有Cell-specific級別和UE-specific級別之分。eNodeB通過SystemInformationBlockType2的timeAlignmentTimerCommon字段來配置的Cell-specific級別的timer；eNodeB通過MAC-MainConfig的timeAlignmentTimerDedicated字段來配置UE-specific級別的timer。如果UE配置了UE-specific的timer，那么UE使用該timer值，否那么UE使用Cell-specific的timer值。當UE收到TimingAdvanceCommand〔來自RAR或TimingAdvanceCommandMACcontrolelement〕，UE會啟動或重啟該timer。如果該timer超時，那么認為上行失步，UE會清空HARQbuffer，通知RRC層釋放PUCCH/SRS，并清空任何配置的DLassignment和ULgrant。當該timer在運行時，UE認為上行是同步的；而當該timer沒有運行，即上行失步時，UE在上行只能發(fā)送preamble。還有一種情況下，UE認為上行同步狀態(tài)由“同步〞變?yōu)椤安煌建暎悍峭紿andover。最后，我們介紹eNodeB是如何處理UE的上行同步呢？由于不同的廠商實現(xiàn)方式可能不同，這里只介紹一些可借鑒的做法?！?〕由于UE必須在timeAlignmentTimer超時之前接收到TimingAdvanceCommand，否那么會認為上行失步。所以eNodeB需要保證在該timer時間范圍內(nèi)〔通常要比該timer小，因為要預(yù)留一些時間給傳輸延遲和UE編解碼等〕給UE發(fā)送TimingAdvanceCommand，以便UE更新上行定時并重啟該timer。所以eNodeB必須保存最近一次成功地給該UE發(fā)送了TimingAdvanceCommand〔即eNodeB收到了對應(yīng)下行傳輸?shù)腁CK〕的子幀號，以便計算該時間范圍?！?〕從〔1〕中可以看出，在eNodeB側(cè)在MAC層也應(yīng)該為每個UE維護一個類似timeAlignmentTimer的timer，以保證在該timer超時之前給UE發(fā)送TimingAdvanceCommand。eNodeB何時啟動/重啟該timer呢？個人認為可以在UE隨機接入成功中后啟動，并在收到對應(yīng)TimingAdvanceCommandMACcontrolelement的ACK/NACK后重啟。注意timer的起始位置應(yīng)該從最近一次成功地給該UE發(fā)送了TimingAdvanceCommand的子幀〔而不是收到對應(yīng)ACK的子幀〕。〔3〕從上面的介紹可以看出，UE在子幀n收到TimingAdvanceCommand后，會從子幀n+6才開始應(yīng)用該timing調(diào)整值。也就是說，eNodeB在子幀n發(fā)送了某個UE的TimingAdvanceCommand之后，在子幀n+6之前〔不包括n+6子幀〕的時間內(nèi)，是不會去測量該UE的上行timing的。〔4〕在子幀n+6之后，eNodeB可能需要測量多個上行timing瞬時值以作平均處理，以便得到最終的調(diào)整量，也就是說，eNodeB可能在n+6子幀后的某段時間內(nèi)，是不會發(fā)送TimingAdvanceCommand的。當測量完畢后，eNodeB在之后的某個子幀將Timing

AdvanceCommand

MACcontrolelement發(fā)給UE。〔5〕eNodeB在物理層〔L1層〕應(yīng)該也會判斷UE在上行是否同步〔具體如何判斷我也不清楚，有位讀者介紹過該廠家的實現(xiàn)機制，供大家參考：物理層會根據(jù)UL信號來計算sinr〔也用于估算TA

值〕，如果算出的sinr值過低，物理層就會認為UL

失步〕，如果不同步，應(yīng)告知MAC層。〔關(guān)于物理層的處理，我也不是很清楚，就不在這里獻丑了