Candidate topics for a RAN2 led Rel-19 NR-NTN-evolution Work Item主体提案编号:RP-232860
一、文档摘要(AI生成)
该文件讨论了潜在的 RAN2 主导的 Rel-19 NR-NTN(非陆地网络)演进工作项目的候选主题。讨论的主要主题包括下行链路覆盖范围增强、强大的通知/警报、上行链路容量/吞吐量增强、移动性增强、增强的 GNSS 操作和再生有效负载。该文件提供了每个主题的理由、目标和工作组。下行链路的覆盖增强旨在最大限度地增加可同时激活的波束数量,并确保所有用户终端均可在卫星覆盖范围内获得服务。强大的通知/警报主题解决了低 SNR 或 NLOS 条件下丢失寻呼消息的问题。上行链路容量/吞吐量增强主题侧重于提高 NR NTN 中的系统容量和单个用户吞吐量。移动性增强主题旨在改善对 NR NTN 的移动性支持。增强型 GNSS 操作主题的重点是提高 NR NTN 中 GNSS 的性能。再生有效负载主题讨论了 NR NTN 中再生有效负载的使用。
- 下行链路覆盖增强
- 理由:优化功率并最大化激活光束的数量
- 目标:提高链路裕度并支持动态功率共享
- 工作组:RAN1 和 RAN2
- 强大的通知/警报
- 理由:解决接收条件差和错过寻呼消息的问题
- 目标:确保同步、设计专用通知/警报消息以及对寻呼/呼叫建立过程的影响
- 工作组:RAN1、RAN2 和 RAN3
- NR NTN 的上行链路容量/吞吐量增强
- 理由:解决资源限制并提高系统容量和UE吞吐量
- 目标:增强UL覆盖性能、卫星资源快速接入、资源复用
- 移动性增强
- 理由:改善 NR NTN 的移动性支持
- 目标:增强移动流程和移交性能
- 工作组:RAN2
- 增强的 GNSS 操作
- 理由:改善 NR NTN 的 GNSS 性能
- 目标:增强 GNSS 操作和准确性
- 工作组:RAN2
- 再生有效载荷
- 理由:在 NR NTN 中使用再生有效载荷
- 目标:定义再生有效负载参数并评估性能
- 工作组:RAN3
二、 RAN1 为中心的 NR-NTN 演进 WI 候选主题
2.1 下行链路覆盖范围增强
2.1.1 必要性论证
未来十年部署的所有 5G 卫星网络卫星(涵盖 FR1 和 FR2 频段,以及 GEO 和 NGSO 星座)预计都将在优化的功耗假设下设计。因此,强烈需要实施 DL 覆盖增强技术,以优化给定目标覆盖范围的 CAPEX 和 OPEX。
由于受限的功率和馈线链路带宽,卫星载荷可能无法在给定时间同时激活所有波束,每个波束的 EIRP 密度都为“标称”值(见 TR 38.821 第 6.1.1 节)。
因此,需要 DL 覆盖增强:
最大化可同时激活的波束数量;
确保所有用户终端都可以在整个卫星覆盖范围内获得服务,同时最大化整体卫星吞吐量并确保所有卫星无线电小区即使没有流量也能保持活动状态,允许新用户加入或防止影响终端用户 QoS。
DL 覆盖增强应该考虑以下方面:
链路层: 提高选定物理信道的链路裕量,以适应 EIRP 的降低。这包括可能的技术,例如增加重复方案或根据物理信道而定的等效技术。应考虑物理信道(例如 PDSCH 和 PDCCH)的链路余量改进,而不影响 SSB 设计。
系统层: 支持高效动态和灵活的波束之间或不同波束模式/尺寸(即宽或窄)之间的功率共享,例如利用网络节能技术。
例如,NGSO 在 FR1 频段操作时,可以假设总波束数量为 1200。这将对应于服务 30° 最小仰角卫星覆盖范围所需的波束数量,波束直径约为 50 公里。
综上所述,由于未来十年卫星网络的功耗优化需求,迫切需要实施 DL 覆盖增强技术,提高卫星网络的效率和服务能力。链路层和系统层都需要考虑各种技术,以最大化波束激活数量、提高整体吞吐量并确保服务质量。
2.1.2 目标
假设
不考虑 SSB 信道增强。
假设 UE 天线增益为 -5.5 dBi。
优先考虑 NGSO:在 TR 38.821 中考虑 LEO set-1@600 km 的参考卫星参数。
在本目标中至少考虑 2 个 Rx UE。
至少考虑 FFS RedCAP 1 Rx UE 用于链路裕量改进。
FFS 是否应考虑 RedCAP UE 半双工约束用于系统级增强。
应考虑以下两步方法:
研究阶段
链路层:
识别/优先考虑需要增强的物理信道。
根据物理信道确定目标链路裕量改进。
识别/优先考虑链路层/物理信道需要哪些增强。
系统层:
定义参考卫星载荷参数(例如波束照射计划约束、总 EIRP)和能耗模型,以及必要的评估方法和相关 KPI。
识别潜在解决方案,以支持跨卫星覆盖范围的波束或不同波束模式/尺寸(即宽或窄)之间的高效动态和灵活的功率共享,优先考虑现有的 3GPP 技术。
规范化阶段
定义适当的下行物理数据和控制信道的链路级增强
例如通过重复技术的增强 [RAN1]
定义适当的系统级增强,以支持跨卫星覆盖范围的波束或不同波束模式/尺寸(即宽或窄)之间的高效动态和灵活的功率共享。
2.2 增强型通知/警报
2.2.1 必要性论证
问题背景: 对于外拨电话或消息,用户可以有意识地选择良好的位置以进行通信。但是,对于仅通过 NTN 的来电服务,用户可能会遇到较差的接收条件,因此错过呼叫和消息,这对于公共安全或紧急呼叫消息尤为不利。当 UE 被放置在口袋、背包或车辆、船只等中,或在存在杂波损耗的条件下,可能会发生这些较差的接收条件场景。
数据支持:TR 38.811 表 6.6.2-3 显示,郊区和农村场景的阴影衰落和杂波损耗导致的 NLOS 损耗可能超过 18 dB。表 6.6.1-1 显示,在 30 度仰角下,大约 10% 的农村用户和 50% 的城市用户将经历 NLOS。
说明:视距(LOS)概率取决于 UE 所处环境和仰角,可从表 6.6.1-1 中获得。参考仰角从 10°到 90°,每 10°为一档。对于 UE 到卫星或 UE 到 HAPS 链路,LOS 概率取自最近的参考仰角。
解决方案:为解决低 SNR 条件(例如 NLOS)下 UE 错过寻呼消息的问题,提出了定义 UE 特定的通知/警报功能。该通知目的是提醒用户移动到更好的 SNR 条件下以建立呼叫。
功能要求:该功能应该能够最大限度地减轻与视距条件下所需的链路余量相比的额外损耗。
关键问题:
如何确保在低 SNR 或 NLOS 条件下 UE 与网络的同步?
如何设计专用的通知/警报消息,以便在正常寻呼失败后 UE 能够在低 SNR 或 NLOS 条件下接收它?
该功能将如何影响网络和 UE 级别的正常寻呼/呼叫建立过程?
额外功能:该功能还可以为公共警告目的而激活。
2.2.2 目标
假设
不考虑对现有 SSB 信号的增强。
适用于所有轨道(GSO 和 NGSO)。
最大限度地减轻高达 18 dB 的额外损耗。
目标包括:
根据与 SA WG [RAN1/2] 的联系,确定通知消息的要求。
通知消息应发送给特定的 UE 或小区中的 UE 子集(因此可以利用传统寻呼程序中的某些 UE 标识符)。
识别并指定支持增强型通知/警报消息及其通过下行物理信道传递(包括寻呼程序影响)的可能解决方案 [RAN1, RAN2, RAN3]。
注意:需要与以下部门协调:
SA1(例如通知要求/消息内容)。
SA2(例如,对寻呼程序的潜在影响)
2.3 NR NTN的上行容量/吞吐量增强
2.3.1 必要性论证
Rel-18的不足: 虽然 Rel-18 中指定了上行覆盖增强功能(例如重复和 DMRS 捆绑),但重复的使用会显著降低系统容量和单个用户的吞吐量,因为它减少了可用于数据的资源。
资源受限: 运营商在现实世界中部署 NR NTN 时,系统资源将非常有限,尤其是在上行链路,特别是在初始阶段,预计只有有限的频谱可用于部署 NR NTN 服务。
覆盖广、用户多:NTN 卫星的覆盖范围非常广,考虑到设备密度,预计大量 UE 将在卫星的覆盖范围内。特别是对于 LEO,大量覆盖范围内的 UE 必须成功传输所需的数据,这意味着需要快速访问和释放卫星资源。
频谱受限: 网络可用的总频谱资源将有限,尤其是在 NR NTN 部署的早期阶段。
资源分配颗粒度: 一些用户将需要比其他用户更高的资源,具体取决于他们的流量模式。因此,进一步细化资源复用可以显著提高系统容量效率。
覆盖有限场景: 一些公司还进一步确定了需要能够分配更高的每个 UE 资源以更好地支持覆盖有限场景中的 VoNR/VoIP 服务。
OCC 技术潜力: 一些公司建议,在低编码率下,使用正交覆盖码 (OCC) 在同一 PRB 中复用多个 UE,并使用每个 UE 的子 PRB 分配可以带来高达 10 倍的上行链路容量增益,同时保持增强的上行链路覆盖。
总体而言,上行容量/吞吐量增强的目的包括:
支持增加系统容量,而不会因重复而牺牲每个 UE 的吞吐量和覆盖性能。
恢复可能因重复而丢失的手持 UE 的每个 UE 上行链路数据速率。
一种上行链路接入方案,可以适应非常广泛的卫星覆盖范围内的许多 UE,具有低延迟和高效的资源使用。
部署前景:所有 FR1 卫星网络都将从此功能中受益匪浅。
2.3.2 目标
假设
目的不是取代 MU-MIMO 功能,而是提高系统容量。
本主题不考虑对 PRACH 的增强。
目标
研究并指定(如果有益)通过正交覆盖码 (OCC) 进行 DFT-s-OFDM PUSCH 增强,包括初始接入 [RAN1],并尝试尽量减少对排放的影响:
确定要针对的潜在容量改进(与传统相比至少 2 倍且不超过 12 倍),同时考虑现实的损伤(例如多普勒、时间变化、相位失真)[RAN1]。
如有必要,指定必要的信令 [RAN2]。
如有必要,相应地更新 RF 要求 [RAN4]。
注意:正交覆盖码跨越 OFDM 符号和/或在 OFDM 符号内。
研究并指定是否有益的零星接入(即基于竞争的 PUSCH)到共享资源池 [RAN1/2]。
FFS PUCCH 增强,如果需要 [RAN1]。