5G NTN(七) 高层(1)

说明：本专题主要基于3GPP协议38.821

1. Idle态移动性增强

1.1 TA问题

1.1.1 TA的大小

1.1.2 针对NTN LEO的移动TA，场景C2和D2

1.1.3 针对NTN LEO的固定TA，场景C2和D2

1.1.3.1 方法1：当UE位置信息无法获取的时候

1.1.3.2 方法2：当UE位置信息可以获取的时候

1.1.3.3 TA方案推荐

1.1.4 当前协议

1.2 Idle/Inactive UE移动性过程的增强

1.3 邻区

2. 连接态移动性增强

2.1 NTN中切换的挑战

2.1.1 切换信令中的延迟

2.1.2 测量有效性

2.1.3 对切换事件的影响

2.1.4 频繁地切换

2.1.5 动态的邻区集

2.1.6 大量UE的切换

2.1.7 传播延迟差对测量的影响

2.2 NTN中的切换增强

2.2.1 测量配置/报告的增强

2.2.2 有条件的切换

2.2.3 切换配置

2.3 NTN中的切换种类

2.3.1 架构分类

2.3.2 Intra-gNB切换（“整体式gNB”）

2.3.3 Intra-DU切换

2.3.4 Intra-gNB/ Inter-DU切换

2.3.5 Inter-gNB切换

2.3.5.1 Xn切换

2.3.5.2 基于5GC的切换

2.3.6 小结

2.4 当前协议（R18）

2.4.1 NTN的测量配置

2.4.2 UE收到handover过程中的RrcReconfiguration时

2.4.3 Conditional Handover

2.4.4 Rach-Less Handover

对于NTN，有以下两种satellite beam和cell(PCI)的映射方案：

方案a：一个PCI（Cell）对应多个Satellite beam
方案b：一个PCI（Cell）对应一个Satellite beam

一个Satellite beam可以由1个或多个SSB beams构成。NR协议中，一个Cell(PCI)可以有最多4/8/64个SSB beams、取决于band。

和TN类似，每个PCI可以使用1个或多个SSB index，以区分不同SSB beams上的发送。

在NTN中，satellite beams和SSB index之间的映射关系也留给实现。

NTN中支持两类UE：1）支持GNSS，2)不支持GNSS (在R18的协议中，仅支持了GNSS的UE)

卫星星历、时间和UE位置会用于移动性相关的内容。

对于跟踪区域（TA）：

对于GEO，当前TA管理不用改变
对于LEO，由于beams会移动、需要研究固定和移动的TA两种方案

1. Idle态移动性增强

1.1 TA问题

1.1.1 TA的大小

对于所有NTN场景中，卫星覆盖的小区面积往往非常大（覆盖几百公里），于是会导致非常大的TA，从而产生以下两个问题：

如果TA太小，会导致在小区边缘移动时，有大量的TAU（Tracking Area Updates）信令
如果TA太大，会导致海量的paging信令负载

相比之下，TAU信令比paging信令更加密集。因此，在实践中，会更倾向于限制TA的范围。

乒乓效应也会产生过多的TAU，这个问题可以通过增加10%~20%的重叠区域以及合理地分配处于小区边缘的UE的TAI列表来解决。

1.1.2 针对NTN LEO的移动TA，场景C2和D2

注意：所有的场景信息可以参考5G NTN(一) 概述和场景

由于卫星的快速运动，导致小区提供的覆盖区域相对于地面上基本静止的UE而言、会快速地改变。于是，UE会出现频繁的TAU，导致UE频繁地向网络发起注册上报TAU信息。这一情况事实上是不可接受的。

如果注册区域包含的地理区域非常大，这一问题会得到减轻，但同时带来paging容量的增加。因此如果使用移动TA方案，需要权衡注册区域的大小与paging容量之间的矛盾。

1.1.3 针对NTN LEO的固定TA，场景C2和D2

1.1.3.1 方法1：当UE位置信息无法获取的时候

为了减少UE频繁地发起TAU过程，设计了一种固定TA的方法。如下图所示，当一个NTN LEO所代表的小区扫过地面时，其广播的TAC（Tracking Area Code）、当其到达下一个地面上固定的TA时会发生改变。

网络对TAC的更新需要依赖星历。UE只负责监听TAI = PLMN ID + TAC，且当其改变时触发TAU。如上图所示，由于地面上的TA是固定的，于是即使卫星1运动到不同的位置，假设原来处于TA1的UE、其在没有运动的情况下依然处于TA1中，不会触发TAU。

这个方法适用于R15的网络过程，且UE不需要知道自己的位置信息。

对于卫星运动中广播的TAC的更新，有两个选项：

“硬切”（hard switch）选项：每个cell对每个PLMN只广播一个TAC，在边缘区域直接从原来的TAC切换到新的TAC，这样可能导致边缘区域的一些抖动，使得边缘区域的UE可能经历TAC2 -> TAC1->TAC2的抖动过程。如下图所示

“软切”（soft switch）选项：一个小区对一个PLMN可以广播多个TAC，在TA边缘处，cell可以自动添加新的TA，并且去除更早的TA（比如始终保留2个TA）。处于TA边缘处的UE，由于会收到2个TA，因此不会触发TAU。该方案可能会增加paging load，需要在paging load和TA抖动之间作出一个权衡。

1.1.3.2 方法2：当UE位置信息可以获取的时候

一种可能的方法是对全球的地理区域进行划分，每一个区域分配一个固定的TAC。在初始注册时，UE会基于其位置信息产生一个TAC（UE和网络均需要保存这个地理区域和TAC的映射规则）。于是，UE便不再依赖网络对TAC的广播，而能够自己检测是否发生了位置区域更新。

1.1.3.3 TA方案推荐

推荐使用固定TA

1.1.4 当前协议

当前协议在SIB1中配置了一个NTN的TAI list。TAI list的作用很多，比如可以用于前面介绍的“软切”方案，再比如可以用于处理和地区/国家政策有关的问题（例如将一个TAI绑定到一个地区/国家）。其在协议中的位置如下所示

38.331

SIB1
|-- CellAccessRelatedInfo
    |-- PLMN-IdentityInfoList
        |-- trackingAreaList-r17

UE收到TAI list之后，在接入的时候上报自己认为最合适的TAI。如下所示：

38.413

LOCATION REPORT
UPLINK NAS TRANSPORT
PATH SWITCH REQUEST
HANDOVER NOTIFY
RRC INACTIVE TRANSITION REPORT
UE CONTEXT MODIFICATION RESPONSE
...
|-- User Location Information
    |-- NR user location information
        |-- NR NTN TAI Information

1.2 Idle/Inactive UE移动性过程的增强

对Idle/Inactive UE来说，其移动性过程基本和陆地网络一样，但需要考虑以下问题：

过于频繁的SI更新过程，暂时没有发现这个现象带来真正的问题
在固定TA的方案中，当小区扫过地面的时候，不能因为频繁的TAU导致很重的信令负担。在这个方案中，由于TA在地面上固定了，卫星的运行不会改变UE所处的TA，因而基本和地面基站的TAU差不多。
当小区位于很高的位置时（比如GEO），UE相对过低的发射功率问题。例如UE如果可以识别是GEO，则可以采取一些方法避免发射功率过低的问题。这个问题留给UE实现。

协议：

在SIB19中包含卫星星历，UE可以通过星历数据获取卫星的位置，从而判断是否是GEO

SIB19-r17
|-- NTN-Config-r17
    |-- EphemerisInfo-r17

UE通过SIB1来判断当前小区是否为NTN小区

38.331 5.2.2.4.1

SIB1zhonNTN中的cellBarred in

38.331 5.2.2.4.2

当UE收到SIB1之后

1.3 邻区

LEO卫星的运行轨迹是可预测的，因此其邻区list也是可预测的。NTN的邻区通过系统消息广播。

38.331 SIB19

2. 连接态移动性增强

注：连接态的移动性简称为切换。

2.1 NTN中切换的挑战

2.1.1 切换信令中的延迟

典型的切换信令过程如下

对于下行，服务中断时间（定义在36.881中）可以定义为从源gNB发出RRCReconfiguration开始、到目标gNB收到RRCReconfigurationComplete为止。对于上行，服务中断时间可以定义为从UE收到RRCReconfiguration开始、到目标gNB收到RRCReconfigurationComplete为止。

于是，对于下行，服务中断时间至少包含2个RTT；对于上行，服务中断时间至少包含1.5个RTT。

在GEO中，这个时间分别是1080ms和810ms（见5G NTN(一) 概述和场景中的最大RTT）。在情况最好的LEO中（600公里、再生模型），这个时间也有25ms和19ms。

2.1.2 测量有效性

对于LEO，卫星的运动会影响测量有效性。需要借助星历和/或者UE位置信息。

对于GEO，测量有效性基本和陆地网路一样。

2.1.3 对切换事件的影响

在陆地网络中，常用A3作为切换的测量标准，即邻区RSRP比本小区RSRP好。但这个测量标注对于NTN而言并不适用。如下图所示：处于TN小区边缘和小区中心的用户、其RSRP差别较大；但处于NTN小区边缘和小区中心的用户、其RSRP差别很小。如下图所示：

上述问题对于GEO和LEO都存在，可能需要借助于星历和/或者位置信息以解决。

2.1.4 频繁地切换

非GEO轨道的卫星，相对于地面固定点有一个非常快的速度，这会导致对于地面上静止或者移动的UE频繁和不可避免的切换。

UE在一个小区中能保持连接（不切换）的时间可以用以下公式计算：

下表给出了一些典型场景中的Time to HO

可以看出，在HO的频率的贡献中，UE的速率相对于卫星的速率实际上是可以忽略的。

2.1.5 动态的邻区集

对于非GEO，由于卫星相对地面的UE有一个非常快的速度，导致UE的邻区集也会经常变化。

对于GEO，邻区集不会是一个问题。

2.1.6 大量UE的切换

NTN网络的小区半径很大，因此可能服务大量的UEs。对于非GEO的卫星，由于小区位置的快速变化，可能导致大量UE的切换。

假设UE在小区中均匀分布，于是对于一个小区，当有一定数量的UE切换出去的时候，就会同时有同样数量的UE切换进来，即整个小区的移动性（切出+切入）近似为2倍的切出速率。

下表给出了小区最大UE数（maximum C-RNTI 65519）时平均的UE切换量

2.1.7 传播延迟差对测量的影响

假设UE当前在一个LEO卫星S1的服务中，而另一个LEO卫星S2即将覆盖到这个UE，则UE应该执行对S2这个邻区的测量，然而从UE到卫星S1和UE到卫星S2的传播延迟差可能显著变化。

如果测量gap配置没有考虑传播延迟差，则UE可能会丢失SSB/CSI-RS的测量窗口，以至于无法完成测量。这个问题对于GEO和LEO都存在，并且在LEO中更应该被优先处理。

2.2 NTN中的切换增强

2.2.1 测量配置/报告的增强

有条件地触发测量上报： UE会基于位置触发测量上报，或者基于位置和RSRP/RSRQ的组合来触发测量上报
在测量报告中包含位置信息：UE可以在Measurement Report中携带位置信息，以辅助基站决定什么时候切换
网络补偿不同卫星之间的传播延迟差：网络可能通过系统消息或UE专有的信令、对传播延迟差进行补偿，以避免UE丢失邻区的SSB/CSI-RS的测量窗口

2.2.2 有条件的切换

基于测量触发：这个是传统的方法，需要注意测量门限的配置需要考虑NTN中小区边缘和小区中心之间信号质量的差异比较小
位置（UE和卫星）触发：增加的触发条件、基于UE和卫星的位置。可以独立考虑，也可以和其它触发条件（比如基于测量）联合考虑
基于时间/定时器的触发：该触发条件考虑终端在一个区域的服务时间。可能基于UTC时间，或者基于一个定时器。可以独立考虑，也可以和其它触发条件（比如基于测量）联合考虑
基于TA值的触发：额外的触发条件、基于到目标小区的TA值。可以独立考虑，也可以和其它触发条件联合考虑
基于源小区和目标小区的仰角的触发：额外的触发条件、基于源小区和目标小区的仰角。可以独立考虑，也可以和其它触发条件联合考虑

下表列出每种方案的利弊

2.2.3 切换配置

一些公共的配置可以通过广播（SIB）来实现。以下标准会用来评估是否应该作为广播信令：

是否有足够数量的UE共享相同的值
这些值是否会在足够长的时间内保持不变、从而不需要频繁地修改
UE需要多久才能收到用于NTN接入所需的最小信息

2.3 NTN中的切换种类

在NTN种，有以下几种不同类型的切换

Intra-satellite hand-over（在同一个卫星的不同小区之间）
Inter-satellite hand-over（在不同卫星的不同小区之间）
Inter-access hand-over（在陆地小区和卫星之间）

NTN的模式又包含透明和再生（分为gNB在卫星上和部分gNB在卫星上），下表给出了所有NTN切换种类对应的场景(表中所有章节号都是38.821中的章节号)

2.3.1 架构分类

在5G NTN(二) NG-RAN架构中，细分一下，一共介绍了5种NTN架构

Transparent based non-terrestrial access network
Regenerative satellite and split gNB
Regenerative satellite and on-board gNB(s)
Regenerative satellite with Inter-Satellite Links (ISLs), gNB processed payload
gNB processed payload, Relay-like architecture （因讨论得很少，故前面的文章种没有描述，详见38.874）

2.3.2 Intra-gNB切换（“整体式gNB”）

架构1/3/4/5支持这种场景，且信令没有影响

2.3.3 Intra-DU切换

仅架构2支持该场景、且对协议没有影响

2.3.4 Intra-gNB/ Inter-DU切换

这个case主要针对架构2，F1信令可能会受影响。

不考虑一个DU跨越多个卫星的场景。

2.3.5 Inter-gNB切换

2.3.5.1 Xn切换

对于架构1/2，Xn接口位于地面基站之间，因此Xn切换是可行的、且不对协议没有任何影响。

架构3中没有Xn接口，故不支持Xn切换。

对于架构4，Xn切换是可行的。

邻区的概念需要考虑两种情形：

两个邻区都属于NTNs
一个邻区属于TN，另一个邻区属于NTN

Xn接口可以通过星间链路来实现。

注：关于当前的星间链路带宽。如果使用激光通信可以达到10~100Gbps，例如Startlink就已经部署了激光通信的星间链路，带宽可以达到10Gbps以上。如果使用射频毫米波，则可以达到几百Mbps甚至Gbps。

2.3.5.2 基于5GC的切换

类似于地面系统的S1-Based切换或者NG-Based切换。

架构1/2，支持这种切换、且不影响协议。

架构3/4/5会受影响，NG traffic需要通过SRI（Satellite Radio Interface）传输。

2.3.6 小结

下表给出了不同的NTN架构对各种切换类型的支持情况

2.4 当前协议（R18）

2.4.1 NTN的测量配置

38.331 SIB2

如果NTN小区广播了用于测量的SMTC参数，则需要保证UE在源小区的传播延迟和到目标小区的传播延迟一样。这段话对应2.2.1中提到的“网络补偿不同卫星之间的传播延迟差”。

38.331 MeasObjectNR

associatedMeasGapSSB2 和associatedMeasGapCSIRS2 ：用于NTN部署场景的、分别基于SSB测量和基于CSI-RS测量的、测量gap。

邻区配置以及邻区的极化方向

ReportConfig见后面的"Conditional Handover"。

2.4.2 UE收到handover过程中的RrcReconfiguration时

38.331 5.3.5.5.2

Note1是指当UE收到RRC重配时，UE需要立即执行切换，甚至可能在ACK（HARQ ACK或者RLC AM ACK）RRC重配消息之前。

Note2是指UE有可能会忽略MIB的读取，如果UE已经获得了用于上行同步的信息后，此时UE可以直接发起上行发送（即RRC重配完成）。

2.4.3 Conditional Handover

Conditional handover(CHO)是一个比较大的topic、且不是专门为NTN而设计的，NTN只是借用了这个流程。这里主要讨论和NTN有关的内容。

CHO是指UE在满足一个或多个HO条件时执行的HO。UE在收到CHO配置时会开始评估执行切换的条件，一旦UE执行了切换、将会停止所有执行条件的评估。

CHO的一般原则有：

CHO配置包含由可能多个候选gNB产生的多个候选小区的配置、也包含由源gNB产生的执行条件
一个执行条件可能包含1或2个触发条件（例如CHO事件A3/A5）。对于一个候选小区，仅支持一个RS类型、至多同时配置2个不同的触发参量（RSRP和RSRQ，或者RSRP和SINR，等等）
在任何CHO执行条件满足之前，当收到不带CHO配置的HO command、或者LTM cell switch command的MAC CE时，UE会执行HO过程，并忽略任何之前收到的CHO配置
在执行CHO的时候，从UE开始和目标小区同步起，UE不再监听源小区

CHO的控制面流程

和普通的handover流程相比，CHO有以下明显的不同：

切换准备阶段，源小区会和多个候选小区执行切换准备的流程
在切换执行阶段，UE会先向源小区发RRCReconfigurationComplete消息，但此时UE还没有真正执行切换。当UE发现满足CHO条件时，才开始真正执行切换，并且和传统的HO流程一样，UE还是会向目标小区发送RRCReconfigurationComplete消息

以上内容来自38.300 9.2.3.4

使用CHO作为NTN的HO方式，最主要的原因是CHO可以避免NTN中由于高延迟而导致的切换决策滞后。使用了CHO，gNB可以提前将切换条件配置给UE，当UE监测到条件满足时，可以立即执行切换。

在RRC层，CHO通过IE conditionalReconfiguration来实现，在这个IE中，可以配置对应的measId，

通过measId绑定用于NTN的切换条件，比如基于时间的（Time Based）或者基于位置的（Location Based）测量配置。当前R18协议中，已经包含了基于位置的ReportConfig事件(Event Dx)和基于时间的ReportConfig事件(Event Tx)

Event D1 (Distance between UE and referenceLocation1 is above threshold1
and distance between UE and referenceLocation2 is below threshold2)
Event D2 (Distance between UE and the serving cell moving reference
location is above threshold1 and distance between UE and a moving
reference location is below threshold2)
CondEvent T1 (Time measured at UE is within a duration from threshold)

具体条件可以查看38.331 5.5.4.15/5.5.4.15a/5.5.4.16

在NG接口和Xn接口上也已经支持了Time Based CHO相关的IE。这个IE是由源小区发给目标小区的，方便目标小区为即将到来的CHO分配必要的资源。

38.413 9.3.1.29 Source NG-RAN Node to Target NG-RAN Node Transparent Container

38.423 9.1.1.1 HANDOVER REQUEST

2.4.4 Rach-Less Handover

RACH-less handover即在切换中不经历RACH msg1/msg2，直接向目标基站发送初始上行包（RrcReconfigurationComplete）的过程。在5G NTN(五) MAC层中已经介绍了RACH-less handover的相关内容，这里主要看一下RRC协议关于RACH-less handover的相关描述。

rach-LessHO这个IE位于reconfigurationWithSync中，而reconfigurationWithSync则用于handover的RRCReconfiguration消息中。

rach-LessHO可以和CG（Configured Grant）一起使用，如果配置了CG，则不需要为RACH-less handover配置上行grant

UE自己会按照CG的配置内部选择一个上行grant(用于发送RRCReconfiguration)，见38.321 5.33或者博文 5G NTN(五) MAC层中的描述。否则，UE会通过rach-LessHO中配置的ssb-Index，监听目标小区的PDCCH中分配的上行grant(用于发送RRCReconfiguration)，见 8.321 5.33或者博文 5G NTN(五) MAC层中的描述。此外，38.213 22.2也说明了为什么需要ssb-Index，如下：