如何查询网站icp备案,大连网站建设意动科技公司,兼职招聘网站,石材做网站细节说明#xff1a;本专题主要基于3GPP协议38.821
目录
1. Idle态移动性增强
1.1 TA问题
1.1.1 TA的大小
1.1.2 针对NTN LEO的移动TA#xff0c;场景C2和D2
1.1.3 针对NTN LEO的固定TA#xff0c;场景C2和D2
1.1.3.1 方法1#xff1a;当UE位置信息无法获取的时候
1.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一个PCICell对应多个Satellite beam方案b一个PCICell对应一个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中支持两类UE1支持GNSS2)不支持GNSS (在R18的协议中仅支持了GNSS的UE)
卫星星历、时间和UE位置会用于移动性相关的内容。
对于跟踪区域TA
对于GEO当前TA管理不用改变对于LEO由于beams会移动、需要研究固定和移动的TA两种方案
1. Idle态移动性增强
1.1 TA问题
1.1.1 TA的大小
对于所有NTN场景中卫星覆盖的小区面积往往非常大覆盖几百公里于是会导致非常大的TA从而产生以下两个问题
如果TA太小会导致在小区边缘移动时有大量的TAUTracking 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所代表的小区扫过地面时其广播的TACTracking 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会基于其位置信息产生一个TACUE和网络均需要保存这个地理区域和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差不多。当小区位于很高的位置时比如GEOUE相对过低的发射功率问题。例如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 networkRegenerative satellite and split gNBRegenerative satellite and on-board gNB(s)Regenerative satellite with Inter-Satellite Links (ISLs), gNB processed payloadgNB 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主要针对架构2F1信令可能会受影响。
不考虑一个DU跨越多个卫星的场景。
2.3.5 Inter-gNB切换
2.3.5.1 Xn切换
对于架构1/2Xn接口位于地面基站之间因此Xn切换是可行的、且不对协议没有任何影响。
架构3中没有Xn接口故不支持Xn切换。
对于架构4Xn切换是可行的。
邻区的概念需要考虑两种情形
两个邻区都属于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需要通过SRISatellite 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需要立即执行切换甚至可能在ACKHARQ ACK或者RLC AM ACKRRC重配消息之前。
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中由于高延迟而导致的切换决策滞后。使用了CHOgNB可以提前将切换条件配置给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可以和CGConfigured 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如下 这段话的意思就是说UE需要通过由ssb-Index指示的SSB监听PDCCH的DM-RS进而解析对应的PDCCH中的上行grant。
RACH-less handover是使用DGDynamic grant还是CG、需要有UE能力指示见38.306 R18中还新增了RACH-less handover在inter-frequency中的UE能力指示见38.306
