基站和终端如何识别出失步

简述：

基站和UE都维护了一个定时器，协议timeAlignmentTimer，内部一般叫做不活动定时器，如果不活动定时器超时，基站侧认为失步（上行失步，有下行数传，触发重同步）；UE侧的timeAlignmentTimer超时，UE也认为失步（下行失步，有上行数传，触发重同步）。

还有一个定时器为TA调整定时器，时间到了就会给UE发送TA MCE调整，一般情况31不下发，但是，不下发次数大于设计值31也会强制下发（保证timeAlignmentTimer不超时）。

引用：

下面来自于：LTE学习笔记：时间提前量 TA_爆椒火龙果的博客-CSDN博客_ta时间提前量

由于不同的厂商实现方式可能不同，这里只介绍一些可借鉴的做法。

        （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层。（关于物理层的处理，我也不是很清楚，就不在这里献丑了！~~）