1. What is TA
TA: Timing Advance, 定時提前，一般用於UE上行傳輸，指爲了將UE上行包在希望的時間到達eNB，預估由於距離引起的射頻傳輸時延，提前相應時間發出數據包。
TAC: Timing Advance Command，定時提前命令，eNB通過發送TAC給UE，告知UE定時提前的時間大小。
2. Why need TA
上行傳輸的一個重要特徵是不同UE在時頻上正交多址接入（orthogonal multiple access），即來自同一小區的不同UE的上行傳輸之間互不干擾。
爲了保證上行傳輸的正交性，避免小區內（intra-cell）干擾，eNodeB要求來自同一子幀但不同頻域資源（不同的RB）的不同UE的信號到達eNodeB的時間基本上是對齊的。eNodeB只要在CP（Cyclic Prefix）範圍內接收到UE所發送的上行數據，就能夠正確地解碼上行數據，因此，上行同步要求來自同一子幀的不同UE的信號到達eNodeB的時間都落在CP之內。
爲了保證接收側（eNodeB側）的時間同步，LTE提出了上行定時提前（Uplink Timing Advance）的機制。
在UE側看來，timing advance本質上是接收到下行子幀的起始時間與傳輸上行子幀的時間之間的一個負偏移（negative offset）。eNodeB通過適當地控制每個UE的偏移，可以控制來自不同UE的上行信號到達eNodeB的時間。對於離eNodeB較遠的UE，由於有較大的傳輸延遲，就要比離eNodeB較近的UE提前發送上行數據。
圖1 上行傳輸的timing對齊
圖1(a)中指出了不進行上行定時提前所造成的影響。
從圖1(b)中可以看出，eNodeB側的上行子幀和下行子幀的timing是相同的，而UE側的上行子幀和下行子幀的timing之間有偏移。
同時可以看出：不同UE有各自不同的uplinktiming advance，也即unlink timing advance是UE級的配置。
3. How measure TA
eNodeB通過測量UE的上行傳輸來確定每個UE的timingadvance值。因此，只要UE有上行傳輸， eNodeB就可以用來估計timing advance值。理論上，UE發送的任何信號（SRS/DMRS/CQI/ACK/NACK/PUSCH等）都可用於測量timingadvance。
在隨機接入過程中，eNodeB通過測量接收到的preamble來確定timing advance值。
4. When send TA
上行同步的粒度爲16Ts（0.52 ms）。關於Ts，見36.211的第4章。
上行timing的不確定性正比於小區半徑，每1 km有大約6.7μs的傳輸延遲（6.7μs / km），LTE中小區最大半徑爲100 km，故最大傳輸延遲接近0.67 ms。上行同步的粒度爲Ts（0.52 ms），故TA的最大值約爲(0.67 * 1000)/0.52 ≈1288。（TA的最大值爲1282，應該是更精確的計算，但計算方法就是這樣的，當然還要將解碼時間考慮在內）
eNodeB通過兩種方式給UE發送TimingAdvance Command：
1. 在隨機接入過程，通過RAR的Timing Advance Command字段發送給UE
這中情況下，eNodeB通過測量接收到的preamble來確定timing advance值，RAR的Timing Advance Command字段共11 bit，對應TA索引值的範圍是0~1282。
圖2 MAC RARfeild
對於隨機接入而言，TA值乘以16Ts，就得到相對於當前上行timing所需的實際調整值NTA=TA*16（單位爲Ts）。
我稱這個過程爲“初始上行同步過程”。
2. 在RRC_CONNECTED態，通過TAC MACCE發送TA給UE
雖然在隨機接入過程中，UE與eNodeB取得了上行同步，但上行信號到達eNodeB的timing可能會隨着時間發生變化：
- 高速移動中的UE，例如運行中的高鐵上的UE，其與eNodeB的傳輸延遲會不斷變化；
- 當前傳輸路徑消失，切換到新的的傳輸路徑。例如在建築物密集的城市，走到建築的轉角時，這種情況就很可能發生；
- UE的晶振偏移，長時間的偏移累積可能導致上行定時出錯；
- 由於UE移動而導致的多普勒頻移等。
因此，UE需要不斷地更新其上行定時提前量，以保持上行同步。LTE中，eNodeB使用一種閉環機制來調整上行定時提前量。
eNodeB基於測量對應UE的上行傳輸來確定每個UE的timingadvance值。因此，只要UE有上行傳輸， eNodeB就可以用來估計timing advance值。理論上，UE發送的任何信號（SRS/DMRS/CQI/ACK/NACK/PUSCH等）都可用於測量timingadvance。
如果某個特定UE需要校正，則eNodeB會發送一個Timing Advance Command 給該UE，要求其調整上行傳輸timing。該Timing Advance Command 是通過Timing Advance Command MAC control element發送給UE的。
Timing Advance Command MAC controlelement由LCID值爲11101（見36.321的Table 6.2.1-1）的MAC PDU subhead指示，且其結構如下（R表示預留bit，設爲0）：
圖3：TimingAdvance Command MAC control element
可以看出，Timing Advance Command字段共6 bit，對應TA索引值TA的範圍是0~63。
UE側會保存最近一次timing advance調整值NTA,old，當UE收到新的Timing Advance Command而得到TA後，會計算出最新的timing advance調整值NTA,new = NTA,old + (TA-31) * 16 （單位爲Ts）。
我稱這個過程爲“上行同步更新過程”。
5. Related paramters
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。
6. UE behavior
如果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相同。（見36.213的4.2.3節）
從上面的介紹可以看出，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。（詳見36.133的7.1.2節）
7. Out of sync
UE在MAC層如何判斷上行同步/失步（詳見36.321的5.2節）：
eNB會通過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收到Timing Advance Command（來自RAR或Timing Advance Command MAC controlelement），UE會啓動或重啓該timer。如果該timer超時，則認爲上行失步，UE會清空HARQ buffer，通知RRC層釋放PUCCH/SRS，並清空任何配置的DL assignment和UL grant。
當該timer在運行時，UE認爲上行是同步的；而當該timer沒有運行，即上行失步時，UE在上行只能發送preamble。
還有一種情況下，UE認爲上行同步狀態由“同步”變爲“不同步”：非同步Handover。
8. eNB implementation
由於不同的廠商實現方式可能不同，這裏只介紹一些可借鑑的做法。
（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 controlelement的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層。（關於物理層的處理，我也不是很清楚，就不在這裏獻醜了！~~）
關於eNodeB側的上行同步處理，大家還可以參考一下中興的一篇專利，見[7]。
原文：https://blog.csdn.net/nenema/article/details/22162623
【參考資料】
[1] TS36.321的5.2節和6.1.3.5節
[2] TS36.213的4.2.3節
[3] TS 36.300的5.2.7.3節和10.1.2.7節
[4] TS36.133的7.1.2節
[5] 《4G LTE/LTE-Advanced for MobileBroadband》的11.5節
[6] 《LTE - The UMTS Long Term Evolution,2nd Edition》的和18.2.1節
[7] 《LTE的時間提前調整方法及基站》 ---中興的一篇專利，介紹eNodeB側如何處理上行同步的。
[8] http://blog.sina.com.cn/s/blog_927cff010101cwk7.html