3GPP Release 19（Rel-19）标志着非地面网络（NTN）从"辅助覆盖"到"网络原生"的根本性转变。在Rel-17/18以透明转发（bent-pipe）架构为主的基础上，Rel-19首次引入完整的星上再生处理能力——gNB功能上星、CU/DU分离架构适配卫星平台、存储转发（Store-and-Forward）模式赋能物联网场景。这一系列变革不仅重新定义了卫星在5G网络中的角色，更对TS 38.300/38.331等核心规范的结构产生了深远影响。
NTN在3GPP的标准化经历了三个Release的渐进式演进。Rel-17（NR NTN Phase 1）首次将卫星引入NR框架，建立了透明转发的基准架构，支持GEO/LEO/MEO基本通信流程。Rel-18（NR NTN Phase 2）在覆盖增强、频段扩展、移动性管理等方面做了补充完善。Rel-19（NR NTN Phase 3）则是一次质的飞跃——从架构层面引入再生载荷和星上处理能力。
graph LR
subgraph Rel-17 Phase 1
A1[透明转发<br/>Bent-Pipe]
A2[GEO/LEO基本接入]
A3[SIB19星历广播]
end
subgraph Rel-18 Phase 2
B1[覆盖增强]
B2[RedCap NTN]
B3[NTN特定移动性优化]
end
subgraph Rel-19 Phase 3
C1[再生载荷<br/>gNB上星]
C2[CU/DU分离<br/>卫星平台]
C3[Store-and-Forward<br/>IoT NTN]
C4[多波束操作<br/>星间切换]
C5[10MHz UE带宽<br/>RedCap/eRedCap]
end
Rel-17 Phase 1 -->|架构基础| Rel-18 Phase 2
Rel-18 Phase 2 -->|能力扩展| Rel-19 Phase 3
style Rel-19 Phase 3 fill:#e1f5fe
Rel-19 NTN的核心工作项（Work Item）编号为RP-234078（NR_NTN_3），在TSG RAN#102会议上正式批准。该WI涵盖六大技术方向：
| 技术方向 | 核心内容 | 影响的主要规范 |
|---|---|---|
| 再生载荷架构 | gNB/DU/CU功能上星 | TS 38.300, TS 38.401 |
| 存储转发模式 | IoT NTN的S&F操作 | TS 38.321, TS 38.331 |
| 覆盖增强 | DL/UL覆盖改进 | TS 38.211, TS 38.214 |
| 多波束操作 | 波束间切换、波束管理 | TS 38.331, TS 38.321 |
| NTN for RedCap | 卫星接入简化终端 | TS 38.306, TS 38.331 |
| 网络定位验证 | 基于网络的UE位置校验 | TS 38.305, TS 38.455 |
在透明转发架构中，卫星仅充当射频中继器——地面信关站（Gateway）承载完整的gNB功能，卫星只做频率转换和功率放大。这种架构简单但时延高：一个GEO卫星的透明转发链路往返时延约540ms，LEO也有约20-40ms的单跳时延。
Rel-19引入的再生载荷架构将gNB的部分或全部功能部署在卫星平台上，数据在星上完成基带处理，无需回传地面即可完成L1/L2/L3协议处理。
图表 2
Rel-19再生载荷的关键创新在于将地面网络成熟的CU/DU分离架构适配到卫星平台。TS 38.401（NG-RAN架构描述）Rel-19版本新增了NTN-specific的CU/DU部署模型：
模型A：完整gNB上星 卫星承载完整的gNB功能（CU-CP + CU-UP + DU），通过馈电链路（Feeder Link）直接与5GC的AMF/UPF连接。这种模型适用于再生载荷能力较强的GEO/HEO卫星，或者大型LEO卫星平台。
模型B：DU上星 + CU地面 卫星仅承载DU功能（RLC/MAC/PHY），CU-CP和CU-UP保留在地面。F1接口通过馈电链路传输。这种模型在时延和处理负荷之间取得平衡——DU在星上处理L1/L2协议，减少馈电链路往返时延对MAC层HARQ的影响，而CU的RRC/SDAP/PDCP功能保留在地面，便于集中管理和资源调度。
模型C：DU + CU-UP上星，CU-CP地面 这是一种混合方案，用户面处理在星上完成以降低用户面时延，控制面保持在地面以简化RRC管理。E1接口穿越馈电链路。
| 部署模型 | 星上功能 | 馈电链路接口 | 适用场景 | 时延优势 |
|---|---|---|---|---|
| 完整gNB上星 | CU-CP+CU-UP+DU | NG | GEO大型卫星 | 用户面+控制面最优 |
| DU上星 | DU | F1 | LEO中型卫星 | HARQ时延降低 |
| DU+CU-UP上星 | CU-UP+DU | E1+F1-C | LEO高性能卫星 | 用户面时延最优 |
透明转发架构中，HARQ-ACK反馈需要经卫星回传到地面gNB，GEO场景下HARQ RTT超过500ms，实际上无法支持HARQ重传。Rel-18对此的解决方案是禁用HARQ或使用极长的HARQ定时器。
再生载荷从根本上解决了这个问题。DU在星上处理MAC层HARQ，UE发送的ACK/NACK直接在卫星上处理，HARQ RTT从540ms降低到与地面网络相当的量级（LEO约4-8ms）。TS 38.321（MAC协议规范）Rel-19版本中新增了regenerative-payload-specific的HARQ时序配置，允许网络为再生载荷场景配置更短的k1值（PDSCH到HARQ-ACK的时隙偏移）。
这一改变对调度效率的提升是数量级的。透明转发场景下，HARQ实际上不可用，只能依赖RLC层ARQ进行重传，效率低下；再生载荷下HARQ恢复正常运作，首次传输成功率可通过快速重传迅速提升。
IoT设备通常传输小数据包（几十到几百字节），对时延不敏感但要求极低的终端复杂度。在LEO卫星场景下，卫星在某个IoT设备上空的可见时间窗口可能只有5-15分钟。如果数据到达时卫星恰好没有馈电链路连接（即卫星不在信关站覆盖范围内），传统架构下这些数据会丢失。
Rel-19引入的Store-and-Forward（S&F）模式解决了这一问题。卫星上的DU/CU在收到UE的上行数据后，可以在本地存储，等到与信关站建立馈电链路连接后再转发。下行方向类似：5GC通过信关站将数据发送到卫星，卫星存储并在飞经目标UE上空时转发。
TS 38.321 Rel-19版本新增了S&F相关的MAC CE（Control Element）和逻辑信道标识。核心机制包括：
上行S&F流程：
图表 3
关键参数包括： - S&F存储时限：通过RRC信令配置最大存储时长，避免过期数据无限占用星上存储 - S&F存储容量指示：卫星通过SIB19或专用RRC信令广播当前可用存储容量 - 数据优先级管理：高优先级数据优先转发，低优先级数据在存储空间不足时可丢弃
Rel-19为IoT NTN引入了一种优化的RRC状态管理。UE在发送完数据后不需要维持RRC_CONNECTED状态，而是利用RRC_INACTIVE状态配合S&F模式。卫星端维持UE的上下文（包括安全上下文和DRB配置），UE下次通过同一卫星（或同一星座中的其他卫星）发送数据时可以快速恢复连接。
TS 38.331 Rel-19版本新增了S&F-Config-r19 IE，包含以下关键字段：
| IE字段 | 类型 | 说明 |
|---|---|---|
maxStorageDuration-r19 |
Integer | 最大存储时长（秒） |
storageSize-r19 |
Enumeration | 可用存储容量等级 |
priorityThreshold-r19 |
Integer | 数据优先级阈值 |
sf-DRX-Cycle-r19 |
Enumeration | S&F专用DRX周期 |
一颗现代LEO卫星通常生成数十到数百个点波束（spot beam），覆盖地面不同的服务区域。每个波束可能有不同的频率配置、时序参数和覆盖特性。在透明转发架构中，所有波束共享同一个地面gNB，波束间切换本质上是同一个gNB内的小区切换。但在再生载荷架构中，星上gNB需要独立管理每个波束的无线资源，波束间切换涉及更复杂的资源协调。
TS 38.300 Rel-19版本第16.x节新增了NTN多波束操作框架，主要增强包括：
统一TA（Timing Advance）管理： 在多波束场景下，不同波束到同一UE的传播时延差异可能达到数百微秒。Rel-19引入了per-beam TA偏移量信令，允许网络为每个波束广播独立的TA补偿参数。UE通过SIB19中的ntn-BeamSpecificTA-r19字段获取当前波束的TA偏移，结合GNSS位置计算精确的上行定时。
波束间快速切换： 传统的小区切换流程（RRC重配置）在NTN场景下因长传播时延而不实用。Rel-19优化了同一卫星内波束间的切换机制，允许使用L1/L2信令（类似于地面网络的LTM——L1/L2 Triggered Mobility）执行波束间切换，避免RRC层信令交互。TS 38.331新增了beamSwitchConfig-r19配置IE，支持以下切换模式：
波束 hopping 支持： 部分卫星系统采用波束跳变（Beam Hopping）技术——不是所有波束同时激活，而是按时间轮流激活。Rel-19在SIB19中新增了beamHoppingPattern-r19字段，广播波束的激活/去激活时间图样。UE据此计算波束的可用时间窗口，在波束激活期间进行数据收发。
不同于波束间切换，星间切换发生在不同卫星之间，涉及不同gNB之间的切换。Rel-19增强了NTN场景下的星间切换机制：
基于星历的预测性切换： 网络利用卫星星历数据预测LEO卫星的轨迹，提前触发切换准备。目标gNB（在目标卫星上）在UE实际进入覆盖范围之前就完成切换资源预留。TS 38.331中通过ntn-CHO-Config-r19扩展了条件切换（CHO）配置，新增卫星轨迹相关的执行条件。
馈电链路切换同步： 卫星在切换馈电链路（从一个信关站切换到另一个）的同时，可能也需要进行星间切换。Rel-19新增了馈电链路切换与接入链路切换的协调机制，避免两者同时执行导致的信令风暴。
RedCap（Reduced Capability，降低能力NR终端）在Rel-17引入，目标是为可穿戴设备、工业传感器等中速IoT场景提供低成本的5G接入。Rel-18引入了eRedCap（enhanced RedCap），进一步降低终端复杂度。Rel-19首次将RedCap/eRedCap终端与NTN结合，允许这些简化终端通过卫星接入5G网络。
这对卫星物联网的商业化意义重大。RedCap终端的成本远低于全功能NR终端，结合卫星覆盖的广域特性，可以实现真正的全球物联网覆盖——传感器、跟踪器、可穿戴设备无需地面基站即可接入网络。
10MHz UE带宽： Rel-19 NTN RedCap UE支持的最大RF带宽为10MHz（对比Rel-17 RedCap的20MHz），这对卫星链路预算和终端复杂度都有积极影响。更窄的带宽意味着更好的噪声抑制能力和更低的基带处理复杂度。
简化RRC流程： RedCap UE通过NTN接入时，使用简化的RRC流程。TS 38.331 Rel-19版本为NTN RedCap引入了专用的UE能力容器，减少了RRC信令的开销——这在NTN场景下尤为重要，因为每一比特的信令开销都意味着额外的卫星功率消耗。
eDRX适配： 卫星覆盖的非连续性（LEO卫星不是始终可见）与eDRX机制天然契合。Rel-19增强了NTN场景下的eDRX配置，允许长达数小时的DRX周期，使UE可以在卫星不可见时进入深度睡眠，仅在卫星飞过上空时唤醒。
覆盖增强与重复传输： RedCap终端的天线增益通常较低（1-2根接收天线 vs 全功能UE的4根），在卫星链路中处于劣势。Rel-19在TS 38.214中为NTN RedCap引入了增强的PDCCH/PDSCH重复传输机制，通过Type B重复（跨时隙重复）提升覆盖。
SIB19（System Information Block 19）从Rel-17引入，是NTN专用的系统信息块，承载卫星星历、TA参数、NTN定时信息等。Rel-19对SIB19进行了重大扩展，使其从简单的星历广播载体演变为NTN操作的综合配置信息集。
TS 38.331 Rel-19版本中SIB19新增和修改的关键字段包括：
| 字段 | Rel-17/18 | Rel-19新增/修改 | 说明 |
|---|---|---|---|
ntn-PayloadType |
无 | 新增 | 指示载荷类型：transparent/regenerative |
ntn-RegenerativeConfig |
无 | 新增 | 再生载荷相关配置 |
sf-Config |
无 | 新增 | Store-and-Forward配置 |
ntn-BeamSpecificTA |
无 | 新增 | 波束级TA偏移量 |
beamHoppingPattern |
无 | 新增 | 波束跳变图样 |
ephemerisInfo |
位置+速度 | 位置+速度+加速度 | 增加加速度项提升预测精度 |
ntn-Timing |
基本NTN定时 | 增强定时 | 支持更精细的时间同步 |
networkVerifyLocation |
无 | 新增 | 网络定位验证参数 |
Rel-17/18的星历信息包含卫星的位置（x,y,z坐标）和速度（vx,vy,vz），使用地心固定坐标系（ECEF）表示。Rel-19在星历数据中新增了加速度信息（ax,ay,az），使得UE可以更精确地预测卫星轨迹，特别是在LEO卫星的高速运动场景下。
以600km轨道高度的LEO卫星为例，其轨道速度约7.5km/s，每秒的位置变化达数公里。仅依赖位置和速度的线性预测，在100ms后可能产生数十米的误差。加入加速度项后，预测精度可以提升一个量级，这对定时提前（TA）计算和波束跟踪至关重要。
星历数据的更新频率也从Rel-18的最小周期进一步缩短，Rel-19支持通过dedicated RRC信令更频繁地更新星历，而不仅依赖SIB19广播。
透明转发架构中，所有定时参考来自地面gNB，卫星只是透明转发的媒介。再生载荷架构中，星上gNB需要独立维护时间同步——这带来了新的挑战。
星载时钟的稳定性问题： 卫星平台上的本地振荡器受温度变化、辐射效应、老化等因素影响，频率稳定度通常为$10^{-8}$到$10^{-6}$量级。即使使用原子钟（铷钟/铯钟），也无法达到地面网络纳秒级同步的精度。
相对论效应： 在GEO高度（35,786km），广义相对论效应使得卫星时钟比地面时钟每天快约45.9微秒；而狭义相对论效应使其慢约7.2微秒。综合效应下GEO卫星时钟每天净快约38.7微秒。LEO卫星的速度更快、轨道更低，相对论效应的方向和幅度都不同。
TS 38.211 Rel-19版本为再生载荷引入了增强的时间同步机制：
GNSS辅助的星载同步： 再生载荷卫星使用星载GNSS接收机获取精确时间参考。GNSS本身已经内置了相对论效应的修正（GPS卫星广播的时钟信号已经过修正），因此星上gNB可以通过GNSS获得优于100ns的同步精度。
馈电链路时间校准： 信关站在馈电链路上发送精确的时间戳信息，卫星端的gNB据此校准本地时钟。Rel-19在TS 38.211中新增了NTN-specific的同步信号配置，支持馈电链路时间校准。
分布式同步框架： 对于包含星间链路（ISL）的星座系统，Rel-19支持通过ISL在卫星之间传递同步信息，形成分布式的时钟同步网络。
Rel-19在TS 38.211和TS 38.214中引入了多项NTN下行覆盖增强措施：
增强的PDCCH聚合等级： NTN场景下，由于长传播距离导致的大路径损耗，PDCCH的覆盖通常受限。Rel-19新增了更高的PDCCH聚合等级（AL=16和AL=32），通过更多的CCE重复提升控制信道覆盖。虽然这会增加PDCCH的资源开销，但在卫星场景下覆盖比效率更重要。
PDSCH重复传输增强： 在Rel-18的Type A重复（时隙内重复）基础上，Rel-19增强了Type B重复（跨时隙重复）的配置灵活性。新增了ntn-PDSCH-Repetition-r19配置，支持更长的重复序列和更灵活的RV（Redundancy Version）模式。
上行链路通常是NTN的瓶颈——终端的发射功率远低于卫星，链路预算紧张。Rel-19的上行增强包括：
Msg3重复传输： 随机接入过程的Msg3（RRC连接请求的第一条上行消息）使用重复传输提升可靠性。TS 38.213 Rel-19版本新增了NTN-specific的Msg3重复配置，支持最多32次重复。
PUSCH DMRS增强： 上行解调参考信号（DMRS）的配置增强了功率提升（power boosting）能力，允许PUSCH DMRS使用更高的发射功率密度。
上行定时提前增强： Rel-19优化了TA补偿机制。在再生载荷场景下，由于gNB在卫星上，TA补偿只需要考虑卫星-UE链路的时延，不需要补偿馈电链路时延。TS 38.211 Rel-19版本新增了regenerativeTA-Offset-r19参数，区分透明和再生载荷的TA计算方式。
Rel-19在NTN场景中引入了网络定位验证（Network-based Location Verification）功能。这是一项与安全相关的重要增强，主要解决两个问题：
监管合规： 许多国家的电信法规要求运营商能够验证UE的实际物理位置，用于紧急呼叫定位、 lawful intercept等。在NTN场景下，UE可能通过远距离卫星接入，传统的小区级定位不再适用。
欺诈防范： 防止攻击者通过伪造GNSS位置信息获取不当服务。
TS 38.305 Rel-19版本新增了NTN定位验证流程。网络侧通过测量UE上行信号的传播时延，结合已知的卫星星历，计算UE的估计位置，并与UE报告的GNSS位置进行比对。如果不一致，网络可以拒绝服务或触发进一步的安全验证。
场景一：GEO宽带卫星 + 再生载荷
- 架构：完整gNB上星（模型A）
- 优势：卫星固定在天空某一点，不需要频繁的星间切换
- 挑战：馈电链路长、时延大（但再生载荷消除了HARQ回传时延）
- 配置建议：HARQ-ACK k1值建议配置为4-8时隙；PDCCH聚合等级建议AL=8起步
场景二：LEO星座 + DU上星 - 架构：DU上星 + CU地面（模型B） - 优势：平衡了星上处理能力和地面管理便利性 - 挑战：频繁的星间切换（每5-15分钟） - 配置建议：CHO触发时间建议基于星历预测提前30秒配置；eDRX周期建议与卫星过境周期对齐
场景三：LEO IoT + Store-and-Forward - 架构：DU上星 + S&F模式 - 优势：无需实时馈电链路，降低对信关站部署密度的要求 - 挑战：数据时延取决于卫星到信关站的飞经间隔 - 配置建议：S&F最大存储时长建议配置为1-4小时（对应LEO卫星半个轨道周期）；IoT UE的eDRX周期建议配置为卫星过境间隔的2倍
Rel-19 NTN增强涉及的核心规范关联如下：
| 规范 | 版本 | NTN相关变化 |
|---|---|---|
| TS 38.300 | V19.x.x | NG-RAN架构新增再生载荷模型 |
| TS 38.331 | V19.x.x | SIB19扩展、S&F配置、波束切换配置 |
| TS 38.321 | V19.x.x | S&F MAC CE、波束切换MAC CE |
| TS 38.211 | V19.x.x | 再生载荷同步信号、增强DMRS |
| TS 38.213 | V19.x.x | Msg3重复、PDCCH聚合等级扩展 |
| TS 38.214 | V19.x.x | PDSCH/PUSCH重复传输增强 |
| TS 38.300 | V19.x.x | NTN多波束操作框架 |
| TS 38.401 | V19.x.x | NG-RAN架构：NTN CU/DU分离 |
| TS 38.306 | V19.x.x | RedCap/eRedCap NTN UE能力 |
Q: 再生载荷和透明转发能否在同一星座中混合部署？
A: 可以。Rel-19规范允许同一星座中不同卫星使用不同的载荷架构。地面网络通过SIB19中的ntn-PayloadType字段向UE指示当前服务卫星的载荷类型，UE据此适配不同的定时和切换行为。但在同一卫星内，所有波束应使用相同的载荷架构。
Q: 再生载荷对卫星平台的处理能力有什么要求？ A: 完整gNB上星需要卫星平台具备基带处理能力。典型估算：一个支持64个点波束的LEO卫星，星上基带处理需要约100-500GOPS的算力（取决于波束带宽和MIMO层数），功耗约200-800W。这对卫星平台的功耗预算和散热设计提出了较高要求，目前主要由大型GEO卫星和新一代大平台LEO卫星支持。DU上星的方案对处理能力要求较低，约50-200GOPS。
Q: Store-and-Forward模式下数据安全如何保障？ A: 数据在卫星上以加密形式存储（PDCP层加密在星上DU/CU完成），即使卫星被物理捕获也无法解密存储的数据。此外，Rel-19支持定期更新安全密钥，并引入了数据过期自动清除机制。对于极高安全要求的场景，建议将S&F最大存储时长配置为较短值（如15分钟）。
Q: NTN RedCap终端与地面RedCap终端有何区别？ A: NTN RedCap终端需要额外的GNSS接收能力（用于位置确定和定时同步），需要支持NTN特定的RRC流程（如SIB19解析、星历处理），并且需要更大的定时提前补偿范围（TA偏移可达数十毫秒级，远大于地面网络）。此外，NTN RedCap终端的eDRX周期可以配置得非常长（小时级），这是地面网络不需要的。
Q: Rel-19 NTN何时可以商用部署？ A: Rel-19规范已于2025年底冻结（Stage 3），2026年3月TSG#110全会确认完成。芯片和设备方面，MediaTek、Qualcomm等已宣布Rel-19 NTN芯片计划，预计2027年初商用。再生载荷的卫星端设备需要更长的研发周期，预计2027-2028年有首批商用卫星部署。IoT NTN的S&F模式可能率先在低轨星座中商用，因为其对星上处理能力的要求相对较低。
本文由「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 等场景全覆盖。
