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
根据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层控制权保留在地面，简化了移动性管理，同时星上处理可以显著减少馈电链路的时延和带宽压力。
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：当前卫星剩余覆盖时长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引入了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） |
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误差，卫星据此进行精细化补偿。
透明转发架构下，上下行定时关系完全由地面gNB控制，卫星仅引入固定的转发时延。再生载荷下，卫星成为定时参考点，TS 38.211中的定时关系必须重新定义。
Rel-19在TS 38.211 Section 5.x中新增了"NTN Regenerative Timing"子句，定义了以下关键定时参数：
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层），同时改善上行分集增益。
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资源。
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支持两种通信模式：
| 模式 | 通信方向 | 速率 | 典型距离 |
|---|---|---|---|
| Mode A（间接） | A-IoT设备 → Enabler → gNB | ~100 kbps | ~10m |
| Mode B（直接） | A-IoT设备 → gNB | ~10 kbps | ~100m |
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反馈时序
Rel-19引入了系统性的网络节能框架（TS 38.300 Section 7.x新增），包括：
下表汇总了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物理层 | 全新规范 |
对于运营商和卫星运营商，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以下。
Rel-19 NTN对UE的影响主要体现在RRC层：
TS 38.306中新增了UE能力参数ntn-RegenerativeSupport-r19，UE需在UE-NR-Capability消息中上报此能力。
Rel-19 NTN的再生载荷架构与以下规范产生新的交互：
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 等场景全覆盖。
