# 5G-Advanced Release 19 NTN非地面网络：从透明转发到再生载荷的架构革命 3GPP Release 19于2025年12月正式冻结，作为5G-Advanced的第二大版本，其中**非地面网络（NTN, Non-Terrestrial Network）**的增强是RAN领域最具变革性的工作项之一。从Rel-17的基础框架到Rel-19的再生载荷（Regenerative Payload）和存储转发（Store & Forward）机制，NTN已从"卫星直连手机"的概念验证阶段迈入了可规模化部署的工程实施阶段。本文基于TS 38.300 V19.1.0、TS 38.331 V19.0.0等核心规范，深度解析R19 NTN的架构设计、协议增强和部署考量。 ## 一、NTN架构演进：从Rel-17到Rel-19的三个阶段 NTN在3GPP的标准化经历了三个关键Release，每一个都在架构能力上实现了质的飞跃：  > *图表 1* **Rel-17**确立了NTN的基本架构：透明转发（Transparent）模式下，卫星仅作为射频中继，gNB位于地面站。这种架构实现简单，但存在馈电链路（Feeder Link）时延大、调度效率低的问题。 **Rel-18**在此基础上优化了覆盖和移动性，引入了UE位置验证和增强的GNSS辅助机制，但核心架构未变。 **Rel-19**则引入了两项根本性架构变革： 1. **再生载荷（Regenerative Payload）**：将gNB的部分或全部协议栈部署在卫星上，使卫星具备独立的MAC调度、RLC/PDCP处理能力 2. **存储转发（Store & Forward, S&F）**：允许卫星在无馈电链路连接时缓存数据，待链路恢复后转发，支持延迟容忍型业务 ## 二、再生载荷架构深度解析 ### 2.1 透明转发 vs 再生载荷：架构对比 根据TS 38.300 V19.1.0 Section 16.x的定义，再生载荷将gNB的功能单元部署在卫星平台之上。这意味着卫星不再是简单的"空中中继器"，而是成为一个完整的无线接入节点。  > *图表 2* **关键差异**在于协议栈的分割点。透明转发模式下，卫星只执行RF放大和频率转换，所有L2/L3处理在地面gNB完成。再生载荷模式下，MAC调度在星上执行，显著降低了调度反馈时延——对于LEO卫星（高度550-1200km），单跳服务链路RTT约10-20ms，而透明转发模式下额外增加的馈电链路RTT可达数十毫秒。 ### 2.2 再生载荷的协议栈部署选项 TS 38.300 V19.1.0定义了再生载荷的多种部署选项： | 部署选项 | 星上部署单元 | 地面部署单元 | 时延优化 | 复杂度 | |----------|-------------|-------------|---------|--------| | 选项A：gNB-DU在星上 | CU-CP/CU-UP分离后的DU | CU-CP, CU-UP | MAC调度在星上 | 中等 | | 选项B：完整gNB在星上 | 完整gNB（含CU+DU） | 5GC/UPF | 全L2在星上 | 高 | | 选项C：CU/DU均在星上+UPF部分功能 | gNB + UPF部分功能 | SMF/AMF | 最优 | 最高 | **选项A**是当前主流部署方案：将gNB-DU（含PHY/MAC/RLC）部署在卫星上，CU-CP和CU-UP通过F1接口连接地面站。这种分割方式在卫星平台功耗、计算能力受限的场景下提供了最佳的性能/复杂度平衡。 **选项B**将完整gNB放在星上，通过NG接口连接地面5GC。这适合具备星间链路（ISL, Inter-Satellite Link）的星座系统，数据可以通过ISL在卫星间路由后再回传到地面。 ### 2.3 再生载荷对MAC层的影响 TS 38.321（MAC层规范）在Rel-19中针对再生载荷引入了以下关键修改： 1. **自主调度增强**：星上MAC实体可以基于本地缓存的BSR（Buffer Status Report）进行自主调度决策，无需等待地面CU的调度指令 2. **HARQ进程数扩展**：考虑到NTN的长传播时延，NTN场景的HARQ进程数从地面NR的最大16个扩展到更多进程数（具体数量取决于卫星轨道高度和配置） 3. **定时提前（TA）补偿**：再生载荷模式下TA计算方式改变，因为gNB-DU在星上，TA仅需补偿服务链路时延，馈电链路时延不再计入TA ## 三、存储转发（Store & Forward）机制 ### 3.1 S&F的应用场景 TS 38.300 V19.1.0中明确引入的存储转发功能，是Rel-19 NTN独有的创新机制。其核心思想是：当卫星不处于地面馈电站的可视范围内时，卫星可以缓存UE的上行数据或下行数据，待卫星飞越馈电站上空时再进行转发。  > *图表 3* S&F机制特别适合以下场景： - **物联网数据采集**：传感器定期上报数据，时延容忍度高 - **远洋/极地覆盖**：地面馈电站稀疏，卫星大部分时间无馈电链路 - **应急通信**：在地面基础设施受损时提供基本通信能力 ### 3.2 S&F的RRC信令支持 TS 38.331 V19.0.0引入了新的RRC IE来支持S&F操作： - **S&F-Config**：包含在SIB19或专用RRC信令中，指示当前小区是否支持S&F模式 - **S&F-DelayBudget**：告知UE可接受的最大存储转发时延，UE据此决定是否使用S&F服务 - **S&F-Availability**：卫星广播的S&F可用性指示，包含当前预计的馈电站连接时间窗口 UE在S&F模式下需要理解数据可能经历较长时延（LEO卫星轨道周期约90-120分钟，最坏情况数据可能存储近一个轨道周期），因此S&F主要面向时延容忍型业务。 ## 四、NTN覆盖增强与物理层优化 ### 4.1 Rel-19覆盖增强要点 Rel-19对NTN的覆盖增强是独立于地面NR覆盖增强的专门工作项。根据TS 38.211 V19.1.0和TS 38.214的修改，关键增强包括： | 增强项目 | Rel-18状态 | Rel-19增强 | 受益方向 | |----------|-----------|-----------|---------| | PUSCH重复次数 | 最大16次 | 扩展至64次（Type A/B均支持） | UL | | PUCCH格式增强 | Format 0/1增强 | 新增长PUCCH重复配置 | UL | | Msg1/Msg3增强 | 基本PRACH增强 | 扩展PRACH preamble格式，增加重复 | UL | | DMRS增强 | 标准DMRS配置 | NTN专用DMRS pattern | UL/DL | | SSB增强 | 基本SSB | NTN专用SSB发送周期和功率Boost | DL | | 频率补偿 | 基于UE速度 | 增强的多普勒预补偿 | UL/DL | 上行覆盖是NTN的瓶颈——终端发射功率有限（通常23dBm），链路预算极其紧张。Rel-19通过大幅增加PUSCH重复次数和引入新的PRACH格式来提升上行覆盖，使更多低功率IoT终端能够接入卫星网络。 ### 4.2 网络侧位置验证增强 Rel-18引入了UE位置验证机制（基于TS 38.305定位框架），但需要UE具备GNSS能力。Rel-19将位置验证能力扩展到**网络侧**： - gNB可以通过测量UE信号的多普勒频移和时延来估计UE位置 - 这对于不具备GNSS能力的RedCap设备或IoT终端尤为重要 - 网络侧位置验证还支持法规合规要求（如紧急呼叫中的位置报告） ## 五、NTN for IoT与RedCap：扩展设备生态 ### 5.1 NTN与RedCap的融合 Rel-19的一个里程碑是将NTN支持扩展到RedCap（Reduced Capability）设备。此前NTN仅支持普通NR UE，RedCap设备由于带宽受限（20MHz FR1）、接收天线数减少（1-2 Rx），在卫星场景下面临更大的链路预算挑战。 Rel-19的NTN-RedCap融合包括： 1. **RedCap专用NTN参数集**：在TS 38.101系列中定义了适用于RedCap终端的NTN频段和功率等级 2. **简化的NTN RRC流程**：针对RedCap设备处理能力有限的特点，优化SIB19的解析和星历信息的处理 3. **增强的DRX配置**：NTN场景下RedCap设备可以配置更长的DRX周期（数百秒级别），以适应卫星过境间隔 ### 5.2 NTN与NB-IoT/mMTC的整合 Rel-19还引入了对NB-IoT和eMTC在NTN场景下的支持增强，包括： - 地球固定跟踪区（Earth-fixed Tracking Area）的优化设计 - 适应卫星移动性的小区重选参数调整 - 针对NB-IoT的简化随机接入流程 ## 六、SIB19与RRC信令的Rel-19演进 SIB19是NTN专用的系统信息块，从Rel-17引入后在每个Release都经历了重要扩展。以下是SIB19在三个Release中的内容对比： | SIB19信息元素 | Rel-17 | Rel-18 | Rel-19 | |---------------|--------|--------|--------| | 卫星星历（Ephemeris） | ✅ 开普勒轨道参数 | ✅ 增强精度 | ✅ 再生载荷星历 | | 星历类型 | 位置+速度 | +轨道根数 | +姿态信息 | | TA补偿参数 | ✅ 基本TA | ✅ 增强TA | ✅ 再生载荷TA | | 参考位置 | ✅ | ✅ | ✅ | | NTN-PLMN信息 | ✅ 基本PLMN | ✅ | ✅ 多PLMN增强 | | S&F配置 | ❌ | ❌ | ✅ 新增 | | 再生载荷指示 | ❌ | ❌ | ✅ 新增 | | 载荷类型指示 | 透明转发 | 透明转发 | 透明/再生/S&F | | NTN专用DRX | ❌ | ❌ | ✅ 新增 | | 位置验证辅助 | ❌ | ✅ UE侧 | ✅ 网络侧增强 | TS 38.331 V19.0.0中新增的关键IE包括： ``` NTN-PayloadConfig ::= SEQUENCE { payloadType ENUMERATED {transparent, regenerative, storeAndForward}, regenerativeDU-Config RegenerativeDU-Config OPTIONAL, sf-Config SF-Config OPTIONAL, onBoardProcessingInd BOOLEAN, ... } SF-Config ::= SEQUENCE { sf-Availability SF-Availability, sf-MaxDelay INTEGER (0..7200), -- 最大存储转发时延（秒） sf-BufferingInd ENUMERATED {enabled, disabled}, ... } ``` ## 七、再生载荷的F1接口分割与O-RAN协同 当采用gNB-DU在星上、CU在地面的分割方案时，F1接口需要适配NTN的特殊条件： 1. **F1-C控制面适配**：CU-CP到DU的F1AP消息需要考虑星地链路的RTT（LEO约10-20ms单向），F1接口的定时器需要相应调整 2. **F1-U用户面适配**：GTP-U隧道需要支持S&F场景下的数据缓存和延迟传输 3. **O-RAN Fronthaul适配**：如果采用O-RAN的O-CU/O-DU分割，前传接口（O-Fronthaul）需要适配卫星平台的传输特性 这与O-RAN联盟的NTN白皮书中描述的部署场景高度一致——O-RAN架构天然适合NTN再生载荷的CU/DU分割，因为O-RAN已经定义了开放的CU-DU接口和RAN智能控制器（RIC），可以扩展用于卫星资源管理。 ## 八、首例Rel-19 NTN连接验证 2025年11月，ESA、MediaTek、Eutelsat（OneWeb）、Airbus等联合宣布实现了**全球首例Rel-19 5G-Advanced NR-NTN连接**。该试验使用OneWeb LEO卫星（轨道高度约1200km），与MediaTek的NR NTN芯片通信，验证了以下关键特性： - 再生载荷下的RRC连接建立 - 增强的PUSCH覆盖 - NTN专用定时提前补偿 - SIB19的正确解析和应用 这一里程碑标志着Rel-19 NTN规范从纸面到现实的跨越，为2026-2027年的商用部署奠定了基础。 ## 九、部署考量与参数配置建议 ### 9.1 透明转发到再生载荷的迁移路径 对于已有Rel-17/18透明转发NTN部署的运营商，向Rel-19再生载荷的迁移可以考虑以下路径： 1. **阶段1**：保持透明转发，升级地面站软件支持Rel-19的覆盖增强特性 2. **阶段2**：在新发射的卫星上部署gNB-DU，通过F1接口连接地面CU 3. **阶段3**：逐步引入ISL，实现卫星间路由和S&F功能 ### 9.2 关键参数配置 | 参数 | 建议值（LEO场景） | 说明 | |------|-------------------|------| | HARQ进程数 | 32-64 | 适应长RTT | | DRX长周期 | 320ms-10.24s | 普通NR UE | | DRX超长周期 | 数十秒至数百秒 | RedCap/IoT | | PUSCH最大重复 | 32-64次 | 覆盖受限场景 | | SSB周期 | 160ms | NTN默认 | | TA更新周期 | 500ms-2s | 视卫星轨道高度 | ### 9.3 与其他规范的关联 - **TS 23.501/23.502**：5GC需要支持卫星接入的移动性管理和会话管理增强 - **TS 29.500系列**：SBI接口需要传递NTN相关的QoS参数 - **TS 38.101-5**：NTN专用频段和RF要求（n255/n256等） - **TS 38.821**：NR支持NTN的解决方案研究报告，包含大量背景技术信息 ## 十、与Direct-to-Cell方案的对比 Rel-19 NTN标准与Starlink等运营商推行的Direct-to-Cell（D2C）方案存在本质区别： | 维度 | 3GPP NTN (Rel-19) | Direct-to-Cell | |------|-------------------|----------------| | 标准化 | 3GPP开放标准 | 专有方案 | | 协议栈 | 完整NR协议栈适配 | 简化/定制协议 | | 网络集成 | 与5GC原生集成 | 独立或有限集成 | | 多厂商互操作 | 支持 | 通常单厂商 | | 再生载荷 | 标准化支持 | 部分实现 | | IoT/RedCap | 标准化支持 | 通常仅智能手机 | | 监管合规 | 内置位置验证等 | 需额外方案 | 3GPP NTN的核心价值在于**开放标准和多厂商互操作性**，这对运营商而言意味着避免厂商锁定、降低TCO。 ## 常见问题 **Q: 再生载荷模式下，卫星上的gNB-DU如何处理切换？** A: 再生载荷的切换比透明转发更复杂。因为gNB-DU在卫星上，当UE需要在不同卫星间切换时，实际上是不同gNB-DU之间的切换。Rel-19通过增强的Xn接口（卫星间Xn可能通过ISL实现）来支持DU间的切换协调。CU-CP位于地面，可以统一管理跨卫星的切换决策。对于LEO星座，切换频率约每5-10分钟一次（取决于卫星数量和轨道参数）。 **Q: S&F模式下如何保证数据可靠性？** A: S&F模式主要面向时延容忍型业务（如IoT数据上报），数据可靠性通过以下机制保障：（1）卫星上的存储模块采用冗余设计；（2）RLC层的AM模式确认在UE与星上DU之间完成；（3）地面网关收到数据后返回端到端确认；（4）如果数据在S&F期间丢失，上层应用负责重传。需要注意S&F不适合URLCC类业务。 **Q: 现网已有的Rel-17透明转发NTN终端能否接入Rel-19网络？** A: 可以。Rel-19向后兼容，透明转发模式继续支持。Rel-17/18终端可以通过SIB19中的payloadType IE识别网络为透明转发模式，并按照Rel-17/18的流程接入。但Rel-19的新特性（如S&F、增强覆盖）需要Rel-19终端才能使用。 **Q: 再生载荷对卫星平台有什么硬件要求？** A: 再生载荷要求卫星平台具备星上处理能力，包括：（1）基带处理单元（可编程FPGA或ASIC），实现PHY/MAC层功能；（2）足够的存储空间用于S&F缓存；（3）ISL通信模块（可选）；（4）稳定的功率预算——基带处理通常额外增加50-200W功耗。目前新一代LEO卫星平台（如OneWeb Gen2、Starlink V2）已具备这些能力。 **Q: NTN与地面NR的小区规划有什么不同？** A: NTN小区规划面临独特挑战：（1）LEO卫星移动导致小区地面覆盖区域持续移动（移动小区, Earth-moving cell），需要地球固定跟踪区的概念来管理TA和寻呼；（2）小区半径通常远大于地面NR（数十到数百公里），频率复用需要特殊设计；（3）相邻卫星的波束协调需要跨卫星的信令交互。Rel-19引入了增强的地球固定跟踪区管理机制来应对这些挑战。 --- > 本文由「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 等场景全覆盖。