NTN(四) RRC related

微信同步更新欢迎关注同名modem协议笔记。

这篇主要是与RRC层相关的内容，按照cell selection/re-selection->idle->connected 的顺序，对涉及NTN的内容进行总结。首先看下NTN RF相关的内容，这部分对应38.101-5这本spec。

NTN freq info

整本38.101-5一共才32页，相比于FR1 的38.101-1的上百页的内容，NTN场景的RF相关内容确实少很多。

从38.101-5 第五章相关的table 可以看到，用于NTN satellite 的只有2个band，分别是n256/n255，都是FDD-FR1 band，其对应的NARFCN，SSB pattern及GSCN信息如上。

考虑到NTN应用场景，其对速率没有特别高的要求，如上表不同的SCS的最大传输带宽配置N_RB如上，相比于地面网络的带宽是要低不少，另外38.101-5中也没有规定任何CA band信息，也可以看出目前NTN场景对于速率的要求不高。

NTN band可配置的信道带宽、SCS及工作频带的组合如上。

NTN UE 的power class也比较单调，NTN band只支持常规的Class 3 23dBm。其他RF相关内容就不多说了，详情直接查看38.101-5.接下来看下cell selection/re-selection相关的内容。

cell selection

网络侧通过SIB1中cellBarredNTN的存在隐含地确定小区的网络类型,即通过SIB1中的cellBarredNTN可以确定该小区是否可用于NTN连接；和Redcap UE 类似，NTN-capable UE在进行小区选择时，要获得SIB1，之后通过SIB1中的cellbarredNTN判断对应小区是否支持NTN 连接，如果cellbarredNTN为barred或SIB1中没有带cellbarredNTN，则NTN-capable UE认为该小区是barred状态。

Measurement rules for cell re-selection

为支持NTN小区重选，3GPP增加了SIB19，其包含NTN相关的卫星辅助信息及有些参数会用于判断是否会启动小区重选测量，RRC层配置的参数结构如下，也把几个相关IE的含义列在下面。

distanceThresh:距serving cell 参考位置的距离，结合referenceLocation用于 RRC_IDLE 和 RRC_INACTIVE 中基于位置的测量启动。每一步代表 50m。

referenceLocation:service cell的参考位置通过 NTN quasi-Earth fixed系统提供，结合distanceThresh用于RRC_IDLE和RRC_INACTIVE中基于位置的测量启动。其包含用作参考位置的位置信息。第一个八位字节的第一个/最左边的位对应最高有效位。

T-service:指示有关通过NTN quasi-Earth fixed系统提供的小区何时将停止为其当前覆盖的区域提供服务的时间信息。

ntn-NeighCellConfigList,ntn-NeighCellConfigListExt:

提供 NTN 邻区的列表，包括它们的 ntn-Config、载波频率和 PhysCellId。该集合包括 ntn-NeighCellConfigList 的所有IE和 ntn-NeighCellConfigListExt 的所有IE。如果ntn-NeighCellConfigListExt 中不存在 ntn-Config，则应在 ntn-NeighCellConfigList中相同的位置提供 ntn-Config。

结合上述参数，38.304在判断启动cell reselection 测量时，加入基于位置测量的NTN场景判断如下：

在判断小区重选的测量是否要启动时，UE要根据SIB19中的distanceThresh和referenceLocation进一步判断，如上图，如果UE和serving cell参考位置referenceLocation的距离比distanceThresh 短，UE可能不会启动对应测量；否则UE就要进行对应测量。

其实在看到这部分由于先入为主(满脑袋都是SIB19)有个很傻的疑问，即为什么SIB19中不带NTN freq的priority info?后来一想，正如SIB19 的定义带的是NTN satellite assistance information，priority info就在SIB2/3/4/5中，根据SIB19中带的freq信息参照上述SIB的内容就可以找到对应的priority info。

根据Quasi-Earth-fixed的定义，这个服务系统主要由Beam提供覆盖，在有限的时间内覆盖一个地理区域，在另一个时间段内覆盖不同的地理区域，结合t-service的定义理解，t-service代表的就是NTN quasi-Earth fixed系统目前地理区域提供有效服务的时间，如果超过了t-service 代表的时间，代表NTN quasi-Earth fixed系统已经换到其他地理区域，所以38.304中有一段针对t-service的描述，大意是如果当前用到了NTN Quasi-Earth-fixed系统提供的服务，UE也支持time-based 测量，UE应该在t-Service之前完成相关的测量，但是UE具体开始测量的时间，spec没有规定，由各家厂商自行决定。

Handover and CHO

之前版本的常规切换过程 NTN 场景也支持，但是在NTN和地面网络之间的移动期间，UE不需要同时连接到NTN和地面网络。NTN-地面网络切换指双向移动，即支持从NTN切换到地面网络和从地面网络切换到 NTN的操作。UE 可以支持基于不同轨道（不同高度的 GSO、NGSO）的切换。R17中的NTN不支持 DAPS 切换。

Conditional Handover

NTN支持以下CHO，UE 可以根据这些条件对候选小区执行CHO：

- 基于 RRM 测量的事件 A4(CondEventA4)；

- 基于时间的触发条件(CondEvent T1)；

- 基于位置的触发条件(CondEvent D1)。

38.300 9.2.3.4中有CHO过程的描述，接下来简单描述下什么是CHO：条件切换（CHO）是仅在满足配置的执行条件时执行的切换过程，网络可以向UE提供与执行条件相关联的多达8个候选小区配置。UE在接收到CHO配置之后保持与源gNB的连接，并开始评估候选小区的CHO执行条件，如果至少一个CHO候选小区满足相应的CHO执行条件，则UE从源gNB分离，对所选候选小区应用存储的相应配置，同步到该候选小区，并通过目标gNB发送RRCReconfigurationComplete消息来完成RRC切换过程，在成功完成RRC切换后，UE释放存储的CHO配置。

CHO引入的具体原因可以查看R2-1903514，具体地说，CHO旨在避免由于延迟测量报告可能无法到达网络而导致的 RLF，或者即使网络侧收到测量报告并且网络决定执行切换，切换命令也会由于UE发生RLF及后续reestablishment过程导致fail。如下图所示：

在CHO场景中，网络会为UE 配置触发条件以决定何时执行切换。当条件满足时，UE 直接执行HO而无需等待来自网络的命令。该过程的优点是可以在无线信道条件变差之前的较早阶段发起HO，增加了消息成功传输的机会。 CHO的基本信令流程如下图所示。

HO相关的capability IE如下：

nonTerrestrialNetwork-r17: 指示UE是否支持NR NTN access

ntn-ScenarioSupport-r17:指示在GSO或NGSO场景是否支持NTN feature，如果UE支持nonTerrestrialNetwork，但是没有包含ntn-ScenarioSupport，则代表UE在GSO和NGSO场景下都支持NTN feature，同时也支持GSO和NGSO场景的mobility。

condHandover-r16:指示UE是否支持conditional handover，包括执行条件、候选小区配置和最多8个候选小区。除NTN频段外，UE应分别为所有FDD-FR1频段、所有TDD-FR1频段、所有TDD-FR2-1频段和所有TDD-FR2-2频段设置一致的能力值。对于NTN，UE应为所有 FDD-FR1 NTN 频段设置一致的能力值。

condHandoverFailure-r16:指示当所选小区被配置为conditional handover的候选小区时，UE是否支持在重建过程中的conditional handover。除NTN频段外，UE应分别为所有FDD-FR1频段、所有TDD-FR1频段、所有TDD-FR2-1频段和所有TDD-FR2-2频段设置一致的能力值。对于 NTN，UE 应为所有 FDD-FR1 NTN 频段设置一致的能力值。

condHandoverTwoTriggerEvents-r16:指示UE是否支持同一执行条件的2个触发事件。如果 UE 支持 condHandover-r16，则必须支持此功能。除NTN频段外，UE应分别为所有FDD-FR1频段、所有TDD-FR1频段、所有TDD-FR2-1频段和所有TDD-FR2-2频段设置一致的能力值。对于 NTN，UE 应为所有 FDD-FR1 NTN 频段设置一致的能力值。

eventA4BasedCondHandover-r17:指示UE是否支持Event A4的conditional handover 即CondEventA4；如果支持CondEventA4时，UE就要在capability中指示支持nonTerrestrialNetwork-r17，也应该在NTN band下显示支持condHandover-r16。

locationBasedCondHandover-r17:指示 UE 是否支持基于位置的conditional handover，即CondEvent D1。支持此功能的 UE 就要在capability中指示支持nonTerrestrialNetwork-r17，也应该在NTN band下显示支持condHandover-r16。

timeBasedCondHandover-r17:指示 UE 是否支持基于时间的conditional handover，即CondEvent T1。支持此功能的 UE 就要在capability中指示支持nonTerrestrialNetwork-r17，也应该在NTN band下显示支持condHandover-r16。

最后是几个相关的Event的总结。

Event D1/CondEvent D1

CondEvent D1 是针对CHO场景配置的Event，总的来说Event D1和CondEvent D1的触发逻辑区别不大，都是为NTN场景下的HO准备的。