# 3GPP Release 19 NTN非地面网络：从透明转发到星上再生处理的架构跃迁 ## 一、NTN在3GPP标准中的演进脉络 3GPP对非地面网络（Non-Terrestrial Network, NTN）的标准化工作始于Release 17，当时以透明转发（bent-pipe）架构为基础，首次将卫星和高空平台（HAPS）引入5G NR体系。Rel-17 NTN的核心贡献在于定义了时延补偿、多普勒频移预补偿、星历信息广播等基础机制，但架构上卫星仅充当射频中继——所有基带处理（gNB功能）仍位于地面站。 Release 18（NTN Phase 2）在此基础上进行了增强，引入了NTN专用的TDD配比优化、覆盖增强以及更多频段支持。然而，架构层面仍以透明转发为主。 **Release 19标志着一次根本性的架构变革**：首次在规范层面正式支持再生载荷（Regenerative Payload），允许卫星上部署完整的gNB或gNB-DU功能。这不仅是技术参数的调整，更是NTN从"附属覆盖"向"独立网络节点"角色的根本转变。  > *图表 1* ## 二、Rel-19 NTN核心架构创新 ### 2.1 再生载荷的三种部署模型 根据TS 38.300 V19.0.0 Section 16.14和TR 38.821的讨论，Rel-19 NTN再生载荷支持以下三种部署架构： | 架构类型 | 卫星载荷功能 | 地面站功能 | 星间链路 | 复杂度 | |---------|------------|-----------|---------|--------| | **全gNB再生** | 完整gNB（CU+DU） | NG接口中继/AMF | 可选 | 最高 | | **gNB-DU再生** | gNB-DU | gNB-CU（地面） | 可选 | 中等 | | **增强透明转发** | 射频+部分L1处理 | 完整gNB | 无 | 最低 | 全gNB再生架构意味着卫星上运行完整的PHY/MAC/RLC/PDCP/RRC协议栈。这对卫星平台的计算能力和功耗提出了极高要求，但带来两个关键优势：**馈电链路不再承载L1/L2信令**（仅传输NGAP/GTP-U），大幅降低馈电链路带宽需求；**切换可以在星间直接执行**（通过Xn接口或星间链路），无需回退地面。 gNB-DU再生架构是Rel-19中最受关注的折中方案。卫星承担PHY和部分MAC层处理（即TS 38.401中定义的Option 2功能分割），地面站运行gNB-CU。这种分割使得RRC层控制权保留在地面，简化了移动性管理，同时星上处理可以显著减少馈电链路的时延和带宽压力。 ### 2.2 NTN-NTN切换：卫星间移动性的突破 Rel-18 NTN仅支持NTN到地面网络的切换（NTN-TN HO）和通过地面站中继的卫星间切换。Rel-19引入了**直接的NTN-NTN切换机制**（TS 38.300 Section 9.2.3.x新增），其信令流程如下：  > *图表 2* NTN-NTN切换的一个独特设计是**基于星历预测的预切换机制**。由于LEO卫星运动是确定性的（轨道参数已知），gNB-CU可以在卫星覆盖范围变化之前就预判切换时机，而不依赖UE的测量报告触发。这在TS 38.331 V19中引入了新的RRC IE `ntn-HandoverPredictionConfig`，包含： - `satelliteEphemerisInfo`：目标卫星的轨道参数 - `predictedHOTime`：预测切换时间窗口 - `targetSatelliteTimingAdvance`：预补偿的TA值 - `coverageDuration`：当前卫星剩余覆盖时长 ### 2.3 SIB19的Rel-19增强 SIB19（TS 38.331 Section 6.3.1）是NTN的专属系统信息块，Rel-19对其进行了重大扩展。新增的关键IE包括： | IE名称 | 功能说明 | Rel-17 | Rel-19新增/修改 | |--------|---------|--------|----------------| | `ntn-RegenerativeConfig` | 再生载荷配置参数 | 不存在 | 新增 | | `satelliteOnBoardProcessingType` | 指示卫星载荷类型（透明/再生） | 不存在 | 新增 | | `ephemerisInfoPerSV` | 每颗卫星的星历信息 | 单卫星 | 扩展为多卫星列表 | | `ntn-TimingAdvancePreCompensation` | TA预补偿值 | 单值 | 支持多波束独立TA | | `feederLinkInfo` | 馈电链路频率和极化信息 | 不存在 | 新增 | | `interSatelliteLinkConfig` | 星间链路配置 | 不存在 | 新增 | | `ntn-DRX-Config` | NTN专用DRX配置 | 基础DRX | 不连续覆盖DRX | 其中`ntn-DRX-Config`的设计尤为关键。LEO卫星的覆盖是间歇性的——一颗卫星可能仅提供10-15分钟的连续覆盖。Rel-19引入了**不连续覆盖模式（Discontinuous Coverage Mode）**下的DRX优化：当卫星离开覆盖区域时，UE进入深度睡眠；卫星返回前，UE根据星历计算唤醒时间，避免无谓的寻呼监听。 ## 三、Rel-19 NTN物理层关键技术 ### 3.1 OCC（Orthogonal Cover Code）多路复用 Rel-19 NTN引入了OCC机制来增强随机接入前导码的容量。在传统NR中，PRACH前导码通过根序列索引和循环移位区分。NTN场景下，由于大时延扩展和多普勒频移，循环移位的可用数量严重受限。 Rel-19在TS 38.211 V19.1.0中新增了对PRACH前导码应用OCC的支持。通过在频域对前导码进行正交覆盖编码（基于Walsh-Hadamard序列），同一根序列+循环移位组合可以支持多个UE同时发起随机接入，理论上前导码容量翻倍。 | 参数 | Rel-18 NTN | Rel-19 NTN | |------|-----------|-----------| | PRACH前导码格式 | Format 0/1/2/3 + A1/B1/C1 | 同左 + 增强格式 | | OCC长度 | 不支持 | 2/4可选 | | 根序列复用 | 仅循环移位 | 循环移位 + OCC | | 时延扩展适应 | Ncs配置 | Ncs + OCC联合设计 | | 最大前导码数/小区 | 64 | 64 × OCC长度（128/256） | ### 3.2 覆盖增强：PUCCH/PUSCH重复与功率控制 Rel-19专门针对NTN场景进行了上行覆盖增强（Work Item: NR Coverage Enhancement, TS 38.300 Section 19.x）。虽然覆盖增强并非NTN专用，但多项增强直接服务于NTN场景： **PUCCH重复次数扩展**：PUCCH Format 1/3/4的最大重复次数从Rel-18的16次扩展到64次。对于卫星场景中路径损耗极大的UE，这种重复增益至关重要。新引入的IE `PUCCH-ConfigExt`中包含`maxPUCCH-Repetition`字段。 **PUSCH Type B重复增强**：引入了动态重复次数指示（DCI Format 0_2新增字段`PUSCH-RepetitionFactor`），允许基站根据当前卫星仰角动态调整重复次数。低仰角时增大重复，高仰角时减少重复以提升吞吐。 **TA预补偿精度提升**：Rel-18的TA预补偿基于卫星位置和UE参考位置计算，精度有限。Rel-19引入了**闭环TA调整**机制：UE通过测量卫星专用参考信号（NTN-RS）反馈TA误差，卫星据此进行精细化补偿。 ### 3.3 再生载荷下的定时关系重构 透明转发架构下，上下行定时关系完全由地面gNB控制，卫星仅引入固定的转发时延。再生载荷下，**卫星成为定时参考点**，TS 38.211中的定时关系必须重新定义。 Rel-19在TS 38.211 Section 5.x中新增了"NTN Regenerative Timing"子句，定义了以下关键定时参数： - **T_offset_regeneration**：卫星载荷处理时延（L1/L2处理时间） - **T_star_onboard**：星上时钟与GNSS时间的偏差（需周期性校准） - **NTA_offset_NTN**：NTN场景下的定时提前偏移量 - **T_isl**：星间链路传播时延（对多跳卫星中继场景） ## 四、Rel-19其他RAN关键增强 ### 4.1 MIMO Phase 5：CSI与波束管理演进 Rel-19的MIMO增强（NR MIMO Phase 5）聚焦于以下几个方向（基于TS 38.214 V19.1.0和RAN1讨论文档）： **CSI端口扩展**：CSI-RS端口数从Rel-18的最多32端口扩展到最多128端口，以支持更大规模的天线阵列。这要求对CSI报告的码本结构进行重新设计（TS 38.214 Section 5.2.2.2.x新增128端口码本）。 **UE发起的波束管理**：Rel-18的波束管理完全由网络侧控制。Rel-19引入了UE自主的波束管理流程——UE可以基于自身测量结果主动发起波束切换请求，通过新MAC CE `UEInitiatedBeamSwitchRequest`通知gNB。这对高速移动场景（如LEO卫星切换）意义重大。 **Multi-TRP增强**：支持非对称下行sTRP/上行mTRP部署，即下行仅通过一个TRP传输，但上行可以同时通过多个TRP接收（上行CoMP）。这对小区边缘用户的上行覆盖改善尤为显著。  > *图表 3* **3Tx上行MIMO**：Rel-19首次支持3天线端口的UE上行MIMO传输。此前NR UE上行最多支持2层（2Tx）。3Tx上行需要UE配备3个发射链路，在TS 38.306中定义了新的UE能力参数`ul-TxSwitchSupport-3Tx`。这一增强可提升上行峰值速率50%（从2层到3层），同时改善上行分集增益。 ### 4.2 RedCap（NR-Light）进一步简化 Rel-19对RedCap设备进行了进一步的能力缩减和功能增强（基于TS 38.306和TS 38.331修改）： | 参数 | Rel-17 RedCap | Rel-18 RedCap | Rel-19 RedCap | |------|-------------|-------------|-------------| | 最大带宽（FR1） | 20 MHz | 20 MHz | **10 MHz** | | 最大带宽（FR2） | 100 MHz | 100 MHz | **可选降低** | | 最大MIMO层数（DL） | 4 | 4 | **1-2** | | 最大调制阶数 | 256QAM | 256QAM | **可选64QAM** | | 最小UE天线数 | 1Rx/2Rx | 1Rx/2Rx | **1Rx** | | PDCCH监听密度 | 标准 | 降低 | **进一步降低** | | 支持语音（VoNR） | 是 | 是 | **可选去除** | Rel-19 RedCap的关键设计理念是**面向极低成本的物联网场景**。通过将带宽从20MHz降至10MHz、MIMO层数从4降至1-2、允许仅1根接收天线，基带处理复杂度可降低约60%。这使得RedCap芯片的BOM成本逼近NB-IoT水平，同时保持比NB-IoT高出一个数量级的数据速率。 新增的`RedCapUE-Indication` RRC IE允许网络识别RedCap设备并分配专用资源，避免RedCap UE与普通NR UE竞争系统消息和RACH资源。 ### 4.3 Ambient IoT（环境物联网） Rel-19引入了一个全新的物联网类别——**Ambient IoT**（A-IoT），这是3GPP体系中首次支持无电池/能量收集设备的通信技术。 A-IoT的技术基础是反向散射通信（Backscatter Communication）：设备本身不产生射频信号，而是通过调制环境中的连续波（Carrier Wave）来传输信息。A-IoT设备可以由射频能量、光能、热能等供电。 TS 38.300 V19.0.0新增了以下A-IoT网络架构要素： - **A-IoT CN Node**：专门处理A-IoT业务的核心网节点，通过gNB连接5GC - **A-IoT Enabler**：辅助A-IoT设备通信的网络功能，负责生成连续波和接收反向散射信号 - **TS 38.391**：全新规范，定义A-IoT的MAC层协议 - **TS 38.371**：全新规范，定义A-IoT的物理层信道和调制 A-IoT支持两种通信模式： | 模式 | 通信方向 | 速率 | 典型距离 | |------|---------|------|---------| | Mode A（间接） | A-IoT设备 → Enabler → gNB | ~100 kbps | ~10m | | Mode B（直接） | A-IoT设备 → gNB | ~10 kbps | ~100m | ### 4.4 NR覆盖增强（非NTN专用） Rel-19的NR覆盖增强工作项覆盖FR1和FR2的所有信道： **PUCCH增强**： - Format 0最大重复从32次扩展到128次 - Format 1最大重复从16次扩展到64次 - 新增PUCCH Group Spreading机制，通过序列分组提升覆盖 **PUSCH增强**： - Msg3 PUSCH重复次数扩展（从TS 38.321的`msg3-Repetitions`扩展） - 引入动态重复指示 - PUSCH跳频与重复的联合优化 **PRACH增强**： - 扩展PRACH前导码功率攀升步长范围 - 支持PRACH重复传输（Rel-19新特性） **MsgB增强**（针对2-step RACH）： - 扩展MsgB PDSCH的TBS（Transport Block Size）范围 - 优化MsgB的HARQ-ACK反馈时序 ### 4.5 网络节能 Rel-19引入了系统性的网络节能框架（TS 38.300 Section 7.x新增），包括： - **Cell Dormancy Enhancement**：支持更细粒度的小区休眠，可独立控制SSB、CSI-RS、寻呼等信号的发送/停止 - **SSB-less操作**：允许空闲态UE在无SSB发送的小区驻留（通过邻区SSB获取时间同步） - **Dynamic DTX/DRX**：基站侧的非连续发送，在低负载时段自动关闭射频发射 ## 五、Rel-19 RAN规范变更总览 下表汇总了Rel-19 RAN领域主要规范的变更情况： | 规范编号 | 规范名称 | Rel-19主要变更 | |---------|---------|--------------| | TS 38.300 | NR和NG-RAN总体描述 | 新增NTN再生载荷架构、A-IoT架构、覆盖增强框架、网络节能框架 | | TS 38.211 | 物理信道与调制 | 新增OCC机制、NTN再生定时关系、A-IoT物理信道 | | TS 38.212 | 多路复用与信道编码 | A-IoT极化码/LDPC配置适配 | | TS 38.213 | 物理层控制过程 | PRACH增强、PUCCH重复扩展、DRX增强 | | TS 38.214 | 物理层数据过程 | CSI端口扩展至128、Multi-TRP增强 | | TS 38.300 S.16.14 | NTN总体描述 | 再生载荷架构、NTN-NTN切换 | | TS 38.331 | RRC协议 | SIB19扩展、新RRC IE（NTN预测切换、RedCap、覆盖增强） | | TS 38.391 | A-IoT MAC协议 | 全新规范 | | TS 38.371 | A-IoT物理层 | 全新规范 | ## 六、现网部署与迁移考量 ### 6.1 再生载荷部署策略 对于运营商和卫星运营商，Rel-19 NTN再生载荷的部署需要考虑以下因素： **频谱规划**：Rel-19 NR-NTN在n252频段（S-band, 1980-2010 MHz UL / 2170-2200 MHz DL）已获得验证。Keysight和Samsung在2026年初完成了n252频段的Rel-19 NR-NTN互联互通测试。MediaTek、ESA、Eutelsat也在2025年11月实现了基于OneWeb LEO卫星的首次Rel-19 NR-NTN连接。 **CU/DU分割选择**：对于LEO星座，推荐采用gNB-DU再生+地面gNB-CU的架构。理由有三： 1. RRC层控制在地面，移动性管理（Xn切换）可以通过地面骨干网高效完成 2. 星上仅部署PHY/MAC，对卫星计算平台要求适中 3. 软件升级可以通过更新地面CU来完成，减少星上软件维护成本 **馈电链路优化**：再生架构大幅降低馈电链路需求。透明转发架构下，每颗卫星需要~500MHz馈电带宽（取决于服务带宽和波束数）；gNB-DU再生架构下，馈电链路仅承载F1接口数据，带宽需求降至~100MHz以下。 ### 6.2 终端侧影响 Rel-19 NTN对UE的影响主要体现在RRC层： 1. **SIB19解析增强**：UE需支持扩展后的SIB19格式，包括多卫星星历列表和再生载荷配置 2. **定时补偿精度**：UE需支持更高精度的TA预补偿（考虑卫星运动的多阶导数） 3. **不连续覆盖DRX**：UE需根据星历自主计算DRX唤醒时间 4. **测量报告增强**：支持NTN-specific测量量（如卫星仰角、多普勒频移估计） TS 38.306中新增了UE能力参数`ntn-RegenerativeSupport-r19`，UE需在`UE-NR-Capability`消息中上报此能力。 ### 6.3 与其他规范的关联 Rel-19 NTN的再生载荷架构与以下规范产生新的交互： - **TS 23.501/23.502**：5GC需要感知NTN接入类型，AMF需支持卫星跟踪区的注册管理 - **TS 29.531**：N2接口（NGAP）需传递NTN-specific信息（如卫星标识、载荷类型） - **TS 38.470/38.473**：F1接口需支持NTN场景下的CU-DU协同（如TA预补偿参数传递） - **TS 33.501**：安全方面，再生载荷意味着密钥材料可能需要在星上处理，引入新的安全边界 ## 常见问题 **Q: 透明转发和再生载荷的核心区别是什么？** A: 透明转发（Rel-17/18）中卫星仅做射频放大和频率转换，所有基带处理在地面站完成。再生载荷（Rel-19）中卫星上运行部分或全部gNB协议栈（PHY/MAC/RLC/PDCP/RRC），可以进行星上解码/编码、调度和切换决策。核心区别在于**卫星是否具有基带处理能力**。再生架构的优势是降低馈电链路需求、减少端到端时延、支持星间直接切换；代价是卫星平台复杂度和功耗显著增加。 **Q: gNB-DU再生和全gNB再生在现网中如何选择？** A: 对于LEO星座，推荐gNB-DU再生（Option 2分割），因为RRC层控制保留在地面，简化了移动性管理和NAS信令交互，软件升级也更灵活。全gNB再生更适合GEO卫星或需要极致低时延的场景（卫星间直接通过Xn接口切换，无需经地面），但对卫星计算平台要求极高（需运行完整RRC/PDCP栈），且密钥管理面临安全挑战。 **Q: Rel-19 NTN对现有Rel-17/18 NTN终端是否前向兼容？** A: 基本前向兼容。Rel-19 NTN保留了Rel-17/18的所有透明转发操作模式。新终端（支持Rel-19）可以同时工作在透明转发和再生载荷网络中。但Rel-17/18终端无法利用Rel-19的新特性（如NTN-NTN直接切换、不连续覆盖DRX、闭环TA调整等）。运营商在升级网络时可以采用**双模部署**：同时广播Rel-17/18和Rel-19的SIB19配置。 **Q: RedCap在Rel-19的进一步简化是否会牺牲覆盖能力？** A: 不会。Rel-19 RedCap的带宽缩减（20MHz→10MHz）和MIMO简化（4层→1-2层）主要降低峰值速率和频谱效率，但通过Rel-19同时引入的覆盖增强（PUSCH/PUCCH重复扩展、PRACH增强），RedCap UE的覆盖性能实际上可能优于Rel-18。带宽缩减后，UE可以将功率集中在更窄的带宽上，获得更高的功率谱密度，反而改善覆盖。 **Q: Ambient IoT和现有NB-IoT/MTC的定位有何不同？** A: NB-IoT和LTE-M（MTC）需要设备具备电池和主动发射能力。Ambient IoT设备可以完全无电池——通过能量收集供电（甚至仅靠读写器的射频能量），通过反向散射通信传输数据。速率极低（~100kbps以下），距离极短（~10-100m），但成本可以降到1美元以下。目标场景是物流标签、零售盘点、环境传感器等超大规模部署。Rel-19 A-IoT填补了3GPP生态中"无源物联网"的空白。 **Q: Rel-19的AI/ML MIMO增强目前处于什么阶段？** A: Rel-19的AI/ML for NR空口在TR 38.843中进行研究。MIMO相关的AI/ML应用主要包括：CSI反馈压缩（用神经网络替代传统量化）、波束预测（基于历史测量预测最优波束）、信道估计增强（用AI改进高频段的信道估计）。Rel-19主要完成框架定义和性能评估，具体标准化方案可能在Rel-20中落地。运营商现阶段可以关注框架定义，无需立即进行设备升级。 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。