相關概念：
1.CP（Cyclic Prefix）循環前綴
2.SRS：Sounding Reference Signal(上行探測參考信號)，作用：上行信道估計，選擇MCS和上行頻率選擇性調度，TDD系統中，估計上行信道矩陣H，用於下行波束賦形。
3.DMRS：DemodulationReference Sgnal，解調參考信號，在LTE中用於PUSCH和PUCCH信道的相關解調。
4.CRS：Cell Reference Signal(小區參考信號) ，1）下行信道質量測量，如RSRP；2）下行信道估計，用於UE端的相干檢測和解調。
5.PCell和SCell：主服務小區（Primary Cell, Pcell )，輔服務小區 （Secondary Cell, Scell ) 。作用：多載波聚合
6.對於5MHz帶寬的小區，能夠支持200個同時處於激活態的用戶；對於更大帶寬的小區，能夠支持至少400個同時處於激活態的用戶。
7.LTE最大的支持范圍是100KM半徑的小區覆蓋。
8.E-UTRA支持不同帶寬的部署場景，包括1.4MHZ、3.0MHZ、5MHZ、10MHZ、15MHZ、20MHZ。
9.timeAlignmentTimer，時間對齊定時器
正文內容：
本文將介紹LTE中的上行同步過程。主要涉及：1）為何需要上行同步；2）eNodeB如何測量上行定時提前量並下發Timing Advance Command；3）eNodeB和UE如何判斷上行失步（eNodeB側只會做一些原理性的介紹，不同廠家的實現可能不同）。
上行傳輸的一個重要特征是不同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的(a)中指出了不進行上行定時提前所造成的影響。
從圖1的(b)中可以看出，eNodeB側的上行子幀和下行子幀的timing是相同的，而UE側的上行子幀和下行子幀的timing之間有偏移。
同時可以看出：不同UE有各自不同的uplink timing advance，也即unlink timing advance是UE級的配置。
前面介紹了為什么需要做uplink timing advance，接下來我們來介紹eNodeB如何測量上行信號以得到每個UE的上行定時提前量以及如何下發Timing Advance Command給UE。
eNodeB通過兩種方式給UE發送Timing Advance Command：
1）在隨機接入過程，eNodeB通過測量接收到preamble來確定timing advance值，並通過RAR的Timing Advance Command字段（共11 bit，對應TA索引值
的范圍是0~1282）發送給UE。
上行同步的粒度為
（0.52 ms）。對於隨機接入而言，值乘以，就得到相對於當前上行timing所需的實際調整值
（單位為
）。關於，見36.211的第4章。
上行timing的不確定性正比於小區半徑，每1 km有大約6.7μs的傳輸延遲（6.7μs / km），LTE中小區最大半徑為100 km，故最大傳輸延遲接近0.67 ms。上行同步的粒度為（0.52 ms），故的最大值約為(0.67 * 1000)/0.52 ≈1288。（的最大值為1282，應該是更精確的計算，但計算方法就是這樣的，當然還要將解碼時間考慮在內）
我稱這個過程為“初始上行同步過程”。
2）在RRC_CONNECTED態，eNodeB需要維護timing advance信息。
雖然在隨機接入過程中，UE與eNodeB取得了上行同步，但上行信號到達eNodeB的timing可能會隨着時間發生變化：
a）高速移動中的UE，例如運行中的高鐵上的UE，其與eNodeB的傳輸延遲會不斷變化；
b）當前傳輸路徑消失，切換到新的的傳輸路徑。例如在建築物密集的城市，走到建築的轉角時，這種情況就很可能發生；
c）UE的晶振偏移，長時間的偏移累積可能導致上行定時出錯；
d）由於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 subhead指示，且其結構如下（R表示預留bit，設為0）：
可以看出，Timing Advance Command字段共6 bit，對應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相同。（見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節）
接下來，我們介紹UE在MAC層如何判斷上行同步/失步（詳見36.321的5.2節）：
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收到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層。（關於物理層的處理，我也不是很清楚，就不在這里獻丑了！~~）
關於eNodeB側的上行同步處理，大家還可以參考一下中興的一篇專利，見[7]。