相关概念：
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]。
来源：CSDN
作者：zhongguorenmei
链接：https://blog.csdn.net/ZhongGuoRenMei/article/details/103242707