首页 › ran › 5G-Advanced R19 NTN非地面网络架构与协议深度解析

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

图表 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

图表 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

图表 3

S&F机制特别适合以下场景: - 物联网数据采集:传感器定期上报数据,时延容忍度高 - 远洋/极地覆盖:地面馈电站稀疏,卫星大部分时间无馈电链路 - 应急通信:在地面基础设施受损时提供基本通信能力

3.2 S&F的RRC信令支持

TS 38.331 V19.0.0引入了新的RRC IE来支持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将位置验证能力扩展到网络侧:

五、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芯片通信,验证了以下关键特性:

这一里程碑标志着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 与其他规范的关联

十、与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 等场景全覆盖。

51学通信知识星球海报-扫码加入