微信同步更新欢迎关注同名modem协议笔记
地面移动系统的传播延迟通常小于 1 毫秒。 相比之下，NTN 中的传播延迟要长得多，延迟从几毫秒到数百毫秒不等，具体取决于星载或机载平台的高度以及 NTN 中的payload类型。 因此对NTN系统，处理如此长的传播延迟就需要修改 NR从物理层到更高层的许多时序方面的设计，包括Timing Advance 机制,先看下38.300中的描述。
38.300 16.14.2
为了适应 NTN 中的传播延迟，通过Common Timing Advance(Common TA)和下图中所示的两个调度偏移 K_offset 和 k_mac 增强了几种定时关系：
Common TA 是配置的偏移量，对应于参考点 (RP) 和 NTN payload之间的 RTT；k_offset是配置的调度偏移量，需要大于或等于service link RTT和Common TA之和；k_mac 是配置的偏移量，需要大于或等于 RP 和 gNB 之间的 RTT。这篇先看TA相关的过程，k_offset和k_mac下篇再说。
对于serving cell，网络侧会广播星历信息(ephemerisInfo)和Common TA参数，例如在SIB 19中会包含用于NTN 接入的卫星辅助信息(NTN-config-r17)。 在连接到 NTN 小区之前，UE 应具有有效的 GNSS 位置以及卫星ephemerisInfo和Common TA。为了在连接到 NTN 小区之前和期间实现同步，UE 根据 GNSS 位置和卫星星历计算服务链路 RTT，并自主预补偿 T_TA。UE通过考虑 UE 位置和卫星ephemerisInfo来计算频率多普勒频移。 如果UE没有有效的 GNSS postion和有效的卫星ephemerisInfo，UE就不会与网络通信，直到两者都重新获得。在connected mode下，UE 应该能够持续更新 Timing Advance 和 frequency pre-compensation。UE可以被配置为在随机接入过程期间或在connected mode中report TA。 在connected mode下，支持事件触发的 Timing Advance report。
service link上经历的瞬时多普勒频移的预补偿将由 UE 执行，Feeder link上经历的多普勒频移和转发器频率误差的管理留给卫星网络实现。
38.211中有关TA描述如下：
DL 和 UL 在上行链路时间同步参考点 (RP) 处帧对齐，偏移量由 N_TA,offset 给出，具体的由上图中的n-TimingAdvanceOffset给出，缺省情况下 ，由serving cell的duplex mode及frequency range 根据38.133 Table 7.1.2-2确定默认值。
相比于R15/16, R17 的38.211 T_TA的计算多了两个参数，分别是N_common_TA,adj 和N_UE_TA,adj，这两个参数主要用于NTN场景，下面是38.213中有关这两个参数的确定方式。
N_UE_TA,adj 由UE的位置和RRC层配置的serving-satellite ephemeris相关参数确定，RRC层没有配置ephemerisInfo时，N_UE_TA,adj=0；如果有配置serving satellite的RRC层 ephemeris参数时，UE要根据N_UE_TA,adj预先补偿service link上的双向传输延迟。 为了预先补偿上行时间同步参考点与serving satellite之间的双向传输延迟，UE需要根据单向传播延迟Delay_common ( t) 进一步确定N_common_TA,adj的值，其中Delay_common (t)确定公式如上 ，主要由ta-Common,ta-CommonDrift,ta-CommonDriftVariant和t_epoch决定。Delay_common(t)是时间 t对应的serving satellite与UL 时间同步参考点之间的距离除以光速的时间量；如果RRC层没有配置 TACommon, TACommonDrift, 和TACommonDriftVariation时，N_common_TA,adj=0。
T430
serving卫星相对于地球上UE的会发生移动，因而serving 卫星辅助信息(satellite ephemeris and common TA parameters)会涉及一个有效性的问题，所以38.331中有增加一个T430用于保证UE可以持续获得有效的serving 卫星的辅助信息，简单的说是通过T430控制UE获得SIB19得到有效的serving 卫星辅助信息，以便保证UE获得的NTN辅助信息始终处于有效期。详细讨论可以查看R1-2212313 On epoch time and validity of assistance information for R17 NR NTN，下面就看下T430的工作机制。
先看38.331中的描述及两个相关参数ntn-UlSyncValidityDuration和epochTime的定义。
ntn-UlSyncValidityDuration:网络侧为辅助信息（serving或neighbour 卫星ephemeris和Common TA参数）配置的有效期，指示 UE 可以应用辅助信息而无需获取新辅助信息的最大时间。ntn-UlSyncValidityDuration 的单位是秒。 value s5 对应 5 秒， value s10 表示 10 秒.... 该参数适用于connected和idle mode的 UE。 如果该字段在 NTN-NeighCellConfig 下的ntn-Config 中不存在，则UE使用来自serving cell辅助信息的有效持续时间。 ntn-UlSyncValidityDuration 的变化不应该导致SI change notification，也不会导致 SIB1中 valueTag 的modification。 ntn-UlSyncValidityDuration 仅在epochTime\ta-Info\ephemerisInfo 中的至少一项更新时才跟着更新一次。
epochTime: 指示 NTN 辅助信息的epoch 时间。 当通过SIB或通过dedicated信令明确提供时，EpochTime 是DL子帧的开始时间，主要是SFN和subframeNR信息。 serving satellite ephemeris和Common TA参数的epochTime参考点为上行时间同步参考点。 如果此字段不存在，则epochTime是调度此 SIB19 的 SI 窗口的结束时间。 当在dedicated配置中提供时，此字段是强制存在的。 如果通过 NTN-NeighCellConfig 提供的ntn-Config 中不存在此字段，则 UE 使用来自serving satellite ephemeris的epochTime，否则该字段就是基于服务小区的Timing定义的，即neighcell中该字段中指示的 SFN和subframe number指服务小区的SFN和subframe。 在切换的情况下，该字段中指示的SFN和subframe number指目标小区的SFN和subframe。epochTime 的变化不会导致SI change notification，也不会导致 SIB1中 valueTag 的modification。
在获取SIB19后，UE要从epochTime指示的子帧开始或restart serving cell的T430，T430的值设置为ntn-UlSyncValidityDuration；UE 应该在ntn-UlSyncValidityDuration 和 epochTime 持续时间结束之前尝试重新获取SIB19，重新获取SIB 19后，又要重新开启T430。
另外一个需要开启T430的场景是进行切换时，reconfigurationwithsync如果包含ntn-UlSyncValidityDuration和epochTime，就要开启T430。
如果在connected mode T430超时，UE要通知MAC层UL 失步，然后重新尝试获得SIB 19，一旦重新获得SIB19，RRC层要及时通知MAC层，UE重新获得了UL 同步。
NTN场景下，T430 控制的UL同步和UL 失步，在MAC 层也有具体的体现，UE 处于uplink synchronization时，可以进行正常的上行传输；如果RRC层由于T430超时，通知MAC层，UE目前处于UL synchronization lost状态，MAC 层要flush 所有的HARQ buffers且不能进行任何UL传输。
T430工作的图示如下:
根据上述协议描述，NTN场景，UE获得无法获得SIB19时，是无法进行UL传输的，假如UE一直无法获得SIB19，UE应该怎么做？UE一直无休止的去decode SIB19 显然不合理，但是38.331 最新R17 h20版本中并未搜到相关场景描述，协议中没有描述到的内容就是没有规定，估计需要UE自行决定相对应的行为，例如可以尝试换其他小区及暂时bar问题小区一段时间都是常见的操作。
Timing Advance report(ta-report)
在connected mode下，UE 需要持续更新 Timing Advance 和 frequency pre-compensation。UE可以配置为在随机接入过程期间或在connected mode中report TA；在connected mode下，也支持事件触发的 Timing Advance report。Timing Advance report相关内容分别在38.331和38.321，总结如下。
在NTN-Config中有一个参数ta-Report用于指示是否有enable ta-report。如果该IE包含在SIB19中时，代表在RRC connection establishmen/RRC connection resueme的RA期间及RRC connection reestablishment期间可以进行TA report；如果ta-Report是通过dedicated 信令在ServingCellConfigCommon中配置给UE时，代表在reconfiguration with sync引起的RA期间可以进行TA reporting。
如果ta-report=true，网络侧会通过MAC-CellGroupConfig 中的tar-Config配置相应的参数offsetThresholdTA(只会给MCG配置)及timingAdvanceSR，TA reporting的相关描述在38.321 5.4.8章节，下面具体来看下。
38.321 5.4.8
Timing Advance reporting 过程用于NTN场景，用于UE 向 gNB 提供UE Timing Advance的估计值，即本篇开头的T_TA。而offsetThresholdTA及timingAdvanceSR用于控制TA reporting 过程。
38.321中描述有三个场景会触发TAR：(1)MAC层收到RRC层要进行TAR 的indication；(2)在RRC层配置 offsetThresholdTA 时，UE 之前没有向当前服务小区报告过Timing Advance值；(3)如果当前Timing Advance 的信息与上次报告的Timing Advance 的信息之间的差异等于或大于 offsetThresholdTA(有配置该参数的情况下)。
MAC层触发了至少1个TAR时，如果当前的UL grant足够发送TAR 就发送对应的Timing Advance Report MAC CE；否则 如果timingAdvanceSR=enabled，就触发SR，待收到UL grant时再发送Timing Advance Report MAC CE。
即使多个事件已触发 Timing Advance 报告，MAC PDU 最多也只能包含一个Timing Advance Report MAC CE。 Timing Advance Report MAC CE 应根据MAC PDU assembly 之前UE的最新估计Timing Advance 值生成。
当前传输的MAC PDU包括相应的 Timing Advance Report MAC CE 时，那当前触发的所有Timing Advance report都应该被取消。
Timing Advance Report MAC CE的结构如上图。
触发TAR的其中一个场景 "MAC层收到RRC层要进行TAR 的indication"，根据38.331中的内容整理如下：
UE要发送RRCReestablishmentRequest和RRCSetupRequest时，如果有配置ta-Report=true,RRC就会通知MAC 进行TAR。
当UE不是截图中的other场景且是通过SRB1收到的RRCReconfiguration时，如果有配置ta-Report=true,RRC就会通知MAC 进行TAR。
上面的内容针对NTN场景下的TA，先后看了下T_TA的计算，T430的工作机制及Timing advance report的内容，和上述内容相关的capability IE 如上。
本篇结束，感谢阅读。