主頁（http://m.by236.com）：技術篇:LTE的上行同步過程

本文將介紹LTE的上行同步過程，主要涉及：

（1）為何需要上行同步；

（2）eNodeB如何測量上行定時提前量并下發Timing Advance Command；

（3）eNodeB和UE如何判斷上行失步（eNodeB側只會做一些原理性的介紹，不同廠家的實現可能不同）。

上行傳輸的一個重要特征是不同UE在時頻上正交多址接入（orthogonal multiple access），即來自同一小區的不同UE的上行傳輸之間互不干擾。

為了保證上行傳輸的正交性，避免小區內（intra-cell）干擾，eNodeB要求來自同一子幀但不同頻域資源（不同的RB）的不同UE的信號到達eNodeB的時間基本上是對齊的。eNodeB只要在循環前綴（Cyclic Prefix）范圍內接收到UE所發送的上行數據，就能夠正確地解碼上行數據，因此上行同步要求來自同一子幀的不同UE的信號到達eNodeB的時間都落在循環前綴范圍之內。

為了保持使用不同循環移位的上行參考信號之間的正交性，也要求接收到的上行參考信號必須是時間對齊的，這也是需要使用上行同步，以保證同一小區的不同UE的上行傳輸在時間上對齊的原因。

為了保證接收側（eNodeB側）的時間同步，LTE提出了上行定時提前（Uplink Timing Advance）的機制。

在UE側看來，timing advance本質上是接收到下行子幀的起始時間與傳輸上行子幀的時間之間的一個負偏移（negative offset）。eNodeB通過適當地控制每個UE的偏移，可以控制來自不同UE的上行信號到達eNodeB的時間。對于離eNodeB較遠的UE，由于有較大的傳輸延遲，就要比離eNodeB較近的UE提前發送上行數據。

圖18-1的(a)中指出了不進行上行定時提前所造成的影響。

從圖18-1的(b)中可以看出，eNodeB側的上行子幀和下行子幀的timing是相同的，而UE側的上行子幀和下行子幀的timing之間有偏移。

同時可以看出：不同UE有各自不同的上行 timing advance，也即上行 timing advance是UE級的配置。

處于上行失步（OUT_OF_SYNC）狀態的UE，還是可以接收下行數據的，但是不能發送上行數據。

前面介紹了為什么需要做上行 timing advance，接下來我們來介紹eNodeB如何測量上行信號以得到每個UE的上行定時提前量以及如何下發Timing Advance Command給UE。

eNodeB通過兩種方式給UE發送Timing Advance Command

（1）在隨機接入過程中，eNodeB通過測量接收到的preamble來確定timing advance值，并通過RAR的Timing Advance Command字段（共11比特，對應TA

索引值的范圍是0~1282）發送給UE。

上行同步的粒度為

（0.52μs）。對于隨機接入而言，

值乘以

，就得到相對于當前上行timing所需的實際調整值NTA = TA´16（單位為

）。

上行timing的不確定性正比于小區半徑，每1 km有大約6.7μs的傳輸延遲（6.7μs / km），LTE中小區最大半徑為100 km，故最大傳輸延遲接近0.67 ms。上行同步的粒度為

（0.52μs），故

的最大值約為(0.67 * 1000)/0.52 ≈1288。（

的最大值為1282，應該是更精確的計算，但計算方法就是這樣的，當然還要將解碼時間考慮在內）

我稱這個過程為“初始上行同步過程”。

（2）在RRC_CONNECTED態，eNodeB需要維護timing advance信息。

雖然在隨機接入過程中，UE與eNodeB取得了上行同步，但上行信號到達eNodeB的timing可能會隨著時間發生變化：

•高速移動中的UE，例如運行中的高鐵上的UE，其與eNodeB的傳輸延遲會不斷變化；

•當前傳輸路徑消失，切換到新的的傳輸路徑。例如在建筑物密集的城市，走到建筑的轉角時，這種情況就很可能發生；

•UE的晶振偏移，長時間的偏移累積可能導致上行定時出錯；

•由于UE移動而導致的多普勒頻移等。

因此，UE需要不斷地更新其上行定時提前量，以保持上行同步。LTE中，eNodeB使用一種閉環機制來調整上行定時提前量。

eNodeB基于測量對應UE的上行傳輸來確定每個UE的timing advance值。因此，只要UE有上行傳輸，eNodeB就可以用來估計timing advance值。理論上，UE發送的任何信號（SRS/DMRS/CQI/ACK/NACK/PUSCH等）都可用于測量timing advance。

如果某個特定UE需要校正，則eNodeB會發送一個Timing Advance Command給該UE，要求其調整上行傳輸timing。該Timing Advance Command是通過Timing Advance Command MAC control element發送給UE的。

Timing Advance Command MAC control element由LCID值為11101（見36.321的Table 6.2.1-1）的MAC PDU subheader指示，且其結構如下（R表示預留比特，設為0）：

Figure 6.1.3.5-1: Timing AdvanceCommand MAC control element

可以看出，Timing Advance Command字段共6比特，對應TA索引值

的范圍是0~63。

UE側會保存最近一次timing advance調整值

，當UE收到新的Timing Advance Command而得到后

，會計算出最新的timing advance調整值

（單位為

）。

我稱這個過程為“上行同步更新過程”。

如果UE在子幀n收到Timing Advance Command，則UE會從子幀n+6開始應用該timing調整值。

如果UE在子幀n和子幀n+1發送的PUCCH/PUSCH/SRS由于timing調整的原因出現重疊，則UE將完全發送子幀n的內容，而不發送子幀n+1中重疊的部分。

UE收到Timing Advance Command后，會調整PCell的PUCCH/PUSCH/SRS的上行發送時間。而SCell的PUSCH/SRS（SCell不發送PUCCH）的上行發送時間調整量與PCell相同。

從前面的介紹可以看出，在Rel-10中，PCell和SCell共用一條Timing Advance Command。在載波聚合中，UE可能需要往多個小區（或稱為component carrier）發送上行數據，在理論上，由于不同小區的物理位置（inter-band CA）可能不同，每個小區都需要給該UE發送各自的Timing Advance Command。但是這種類型的部署并不常見，載波聚合的小區通常物理位置上相近且同步，因此為了簡化LTE的設計，所有聚合的小區共用一條timing advance command。

前面已經介紹過，上行定時提前的調整量是相對于接收到的下行子幀的timing的，因此在UE沒有收到Timing Advance Command的時候，UE需要跟蹤下行timing的變化，以便自動調整上行傳輸的timing。

接下來，我們介紹UE在MAC層如何判斷上行同步/失步：

eNodeB會通過RRC信令給UE配置一個timer（在MAC層，稱為timeAlignmentTimer），UE使用該timier在MAC層確定上行是否同步。

需要注意的是：該timer有Cell-specific級別和UE-specific級別之分。

eNodeB通過SystemInformationBlockType2的timeAlignmentTimerCommon字段來配置的小區特定級別的timer；eNodeB通過MAC-MainConfig的timeAlignmentTimerDedicated字段來配置UE特定級別的timer。

如果UE配置了UE特定的timer，則UE使用該timer值，否則UE使用小區特定的timer值。

當UE收到Timing Advance Command（來自RAR或Timing Advance Command MAC control element），UE會啟動或重啟該timer。如果該timer超時，則認為上行失步，UE會清空HARQ buffer，通知RRC層釋放PUCCH/SRS，并清空任何配置的DL assignment和UL grant。

當該timer在運行時，UE認為上行是同步的；而當該timer沒有運行，即上行失步時，UE在上行只能發送preamble。

還有一種情況下，UE認為上行同步狀態由“同步”變為“不同步”：非同步Handover。

最后，我們介紹eNodeB是如何處理UE的上行同步呢？由于不同的廠商實現方式可能不同，這里只介紹一些可借鑒的做法。

（1）由于UE必須在timeAlignmentTimer超時之前接收到Timing Advance Command，否則會認為上行失步。所以eNodeB需要保證在該timer時間范圍內（通常要比該timer小，因為要預留一些時間給傳輸延遲和UE編解碼等）給UE發送Timing Advance Command，以便UE更新上行定時并重啟該timer。所以eNodeB必須保存最近一次成功地給該UE發送了Timing Advance Command（即eNodeB收到了對應下行傳輸的ACK）的子幀號，以便計算該時間范圍。

（2）從（1）中可以看出，在eNodeB側在MAC層也應該為每個UE維護一個類似timeAlignmentTimer的timer，以保證在該timer超時之前給UE發送Timing Advance Command。eNodeB何時啟動/重啟該timer呢？

個人認為可以在UE隨機接入成功中后啟動，并在收到對應Timing Advance Command MAC control element的ACK/NACK后重啟。注意timer的起始位置應該從最近一次成功地給該UE發送了Timing Advance Command的子幀（而不是收到對應ACK的子幀）。

（3）從上面的介紹可以看出， UE在子幀n收到Timing Advance Command后，會從子幀n+6才開始應用該timing調整值。也就是說，eNodeB在子幀n發送了某個UE的Timing Advance Command之后，在子幀n+6之前（不包括n+6子幀）的時間內，是不會去測量該UE的上行timing的。

（4）在子幀n+6之后，eNodeB可能需要測量多個上行timing瞬時值以作平均處理，以便得到最終的調整量，也就是說，eNodeB可能在n + 6子幀后的某段時間內，是不會發送Timing Advance Command的。當測量完畢后，eNodeB在之后的某個子幀將Timing Advance Command MAC control element發給UE。

（5）eNodeB在物理層（L1層）應該也會判斷UE在上行是否同步（例如：物理層會根據UL信號來計算SINR（也用于估算TA° 值），如果算出的SINR值過低，物理層就會認為UL°失步），如果上行不同步，應告知MAC層。