3
GPP在
R2-2002413中将2-step RA引入，进而R16 38.321出现了 Absolute TAC MAC CE，在
NR Timing Advance(TA)_ntn rrc-CSDN博客 有提到这个MAC CE，当时以“absolute timing advance command MAC CE 在2-step RA的某个场景下使用”一笔带过，主要原因就是还没有搞清楚。
这个MAC CE何时使用在38.321有部分描述，如下：
Absolute Timing Advance Command MAC CE 主要应用在MsgA 包含C-RNTI MAC CE且PTAG TAT not run的场景，UL失步就是其中一个场景。
进一步的，根据上面的描述，在TAT not run时，UE收到C-RNTI加扰CRC的PDCCH 后，MAC PDU有包含Absolute Timing Advance Command MAC CE，就要开启TAT；收到Absolute TAC MAC CE后，msgB-ResponseWindow就会停止(也就是收到了msgB，即Absolute TAC MAC CE)，
也就代表RA过程成功完成。
之后有通过在3gpp官网上搜索Absolute TAC MAC CE，试图找到其具体应用场景，但是并没有找到特别满意的答案。直
到不经意间看到了38.523-1。
然后在TS
38.523-1 UE conformance specification
7.1.1.1.7~7.1.1.1.9 这个3个章节的测试步骤中看到了
有关Absolute Timing Advance Command MAC CE的应用场景：这里的场景包括
TAT expiry后 UE 通过2-STEP RA重新获得UL同步的测试场景，其中也具体描述了Absolute TAC要什么时候发给UE；
除此之外还有配置2-STEP cfra资源的HO场景，到这里才有种恍然大悟的感觉。
部分截图如上，对这个Absolute TAC MAC CE的应用感兴趣的，可以直接去38.523-1中翻看具体流程。
Absolute Timing Advance Command MAC CE 主要应用在MsgA 包含C-RNTI MAC CE且PTAG TAT not run的场景，UL失步就是其中一个场景。进一步的，根据上面的描述，在TAT not run时，UE收到C-RNTI加扰CRC的PDCCH 后，MAC PDU有包含Absolute Timing Advance Command MAC CE，就要开启TAT；收到Absolute TAC MAC CE后，msgB-ResponseWindow就会停止(也就是收到了msgB，即Absolute TAC MAC CE)， 也就代表RA过程成功完成。之后有通过在3gpp官网上搜索Absolute TAC MAC CE，试图找到其具体应用场景，但是并没有找到特别满意的答案。直到不经意间看到了38.523-1。
然后在TS 38.523-1 UE conformance specification 7.1.1.1.7~7.1.1.1.9 这个3个章节的测试步骤中看到了 有关Absolute Timing Advance Command MAC CE的应用场景：这里的场景包括 TAT expiry后 UE 通过2-STEP RA重新获得UL同步的测试场景，其中也具体描述了Absolute TAC要什么时候发给UE； 除此之外还有配置2-STEP cfra资源的HO场景，到这里才有种恍然大悟的感觉。
部分截图如上，对这个Absolute TAC MAC CE的应用感兴趣的，可以直接去38.523-1中翻看具体流程。