3GPP Release 19作为5G-Advanced的第二个版本，于2025年12月完成标准冻结。如果说Rel-18开启了5G-Advanced的大门，那么Rel-19则是在控制面协议栈层面完成了一次系统性的"进化升级"。本文聚焦5G核心网三大核心协议——PFCP（TS 29.244 V19.3.0）、NAS（TS 24.501 V19.x.x）和GTP-U（TS 29.281 V19.x.x），深度解读Rel-19在信令流程、信息元素（IE）、服务质量监控等方面引入的关键增强。
这三大协议构成了5G核心网控制面的"神经系统"：NAS承载终端与核心网之间的移动性和会话管理信令，PFCP定义SMF与UPF之间的会话控制规则，GTP-U则负责用户面数据隧道的封装与传输。Rel-19对它们的增强，标志着5G网络从"尽力而为"向"确定性服务"的根本性转变。
PFCP（Packet Forwarding Control Protocol）定义于TS 29.244，是SMF控制UPF行为的核心协议。Rel-19对PFCP的增强主要集中在以下方向：
| 增强方向 | 关键Work Item | 影响范围 |
|---|---|---|
| 增强型QoS监控 | URLLC增强 | PFCP Session |
| 时间敏感通信（TSC） | 5GS TSC集成 | PFCP Association + Session |
| 多路径UPF控制 | Multi-path UPF | PFCP Session |
| NTN卫星传输优化 | NTN增强 | PFCP Session |
| Ambient IoT适配 | 低功耗IoT | PFCP Session |
| 节能机制 | UPF能量管理 | PFCP Association |
图表 1
Rel-19在TS 29.244 Section 5.24和Section 8.2中引入了增强型QoS监控（Enhanced QoS Monitoring），这是对Rel-17/18基础的QoS监控的重大升级。
关键变化对比：
| 参数/IE | Rel-18 | Rel-19 |
|---|---|---|
| QoS Monitoring类型 | 上行/下行包延迟 | 上行/下行包延迟 + 逐包抖动 + 丢包率 |
| 测量粒度 | Per QoS Flow | Per SDF（Service Data Flow） |
| 报告触发 | 周期性/事件触发 | 周期性 + 阈值越限触发 + 统计报告 |
| Requested QoS Monitoring IE | 基础3种标志位 | 新增 Jitter Monitoring / Packet Loss Rate / Congestion Level 标志 |
| 测量位置 | NG-RAN ↔ PSA UPF | 新增 UPF间（N9接口） 端到端测量 |
| 时间戳精度 | 微秒级 | 纳秒级精度（用于TSC场景） |
在Rel-19中，SMF通过PFCP Session Establishment Request向UPF下发增强的QoS Monitoring规则，关键流程如下：
图表 2
新增IE详解：
TS 29.244 V19.x.x Section 8.2.167中，Requested QoS Monitoring IE进行了扩展：
同时新增了QoS Monitoring Per Flow IE，允许SMF对同一PFCP Session内的不同SDF分别设置不同的监控策略——这在URLLC场景中尤其关键，因为同一会话可能同时承载高可靠业务和普通业务。
Rel-19对TS 29.244 Section 5.26进行了大幅扩展，以支持时间敏感通信在5G核心网中的深度集成。
关键增强：
时钟漂移测量与报告：SMF可请求UPF测量外部时间源（如gPTP Grandmaster）与5GS内部时钟之间的漂移，并通过PFCP Session Report上报。新增IE Clock Drift Report。
TSN端口管理：UPF作为TSN Translator时，SMF通过PFCP下发TSN端口管理信息，新增 TSN Port Management IE（Section 8.2.xxx），包含： - Port ID - Time-Aware Scheduler参数 - Gate Control List（GCL）
时间同步容差配置：新增 Time Synchronization Tolerance IE，允许SMF为不同业务配置不同的时间同步精度要求（从微秒到纳秒级）。
Rel-19引入了对多路径（Multi-Path）UPF 的PFCP控制能力。在5G-Advanced的URLLC增强场景下，终端可能通过多个NG-RAN节点同时连接到同一UPF，以实现冗余传输。
在PFCP Session Establishment中，SMF可通过新增的 Multi-Path Data Forwarding IE 指示UPF： - 建立多条并行的数据转发隧道 - 配置冗余复制/消除策略 - 设置路径切换的触发条件
Rel-19在TS 24.501中引入了针对非地面网络（NTN） 场景的重要定时器扩展。由于卫星通信中RTT（往返时延）可达数百毫秒甚至秒级（GEO卫星约540ms），传统5G NAS定时器在NTN场景下频繁超时。
关键定时器调整：
| 定时器 | 默认值（地面） | Rel-19扩展值（NTN） | 影响的信令流程 |
|---|---|---|---|
| T3510（Registration） | 5s | 最高 60s | Registration Request |
| T3511（Periodic Registration） | 5s | 最高 60s | Periodic Registration |
| T3521（Deregistration） | 5s | 最高 60s | Deregistration Request |
| T3540（Service Request） | 5s | 最高 60s | Service Request |
| T3517（PDU Session Establishment） | 10s | 最高 120s | PDU Session Setup |
| T3525（PDU Session Modification） | 5s | 最高 60s | PDU Session Modify |
这些扩展通过Registration Accept消息中新增的 Extended NAS Timer IE 下发给UE。AMF根据当前服务小区是否为NTN小区来决定是否启用扩展定时器。
Rel-19在TS 24.501 Section 5.5中引入了按需注册（On-Demand Registration） 概念，主要针对以下场景：
5GMM状态机扩展：
图表 3
On-Demand Registration的信令流程：
UE在Registration Request中通过 5GS Registration Type IE 新增的"On-Demand"值（Bit组合）指示希望进行按需注册。AMF在Registration Accept中携带 On-Demand Registration Parameters IE，包含：
Rel-19在TS 24.501 Section 4.4中引入了以下NAS安全增强：
GTP-U定义于TS 29.281，负责在N3（gNB-UPF）和N9（UPF-UPF）接口上封装用户面数据。Rel-19对GTP-U的增强围绕确定性传输和多路径冗余展开。
新增GTP-U Extension Header：
| Extension Header类型 | 用途 | 适用接口 |
|---|---|---|
| Delay Measurement | 端到端延迟测量 | N3/N9 |
| Redundancy Tag | 冗余传输标识 | N3 |
| TSC Timestamp | TSN时间戳 | N3/N9 |
| Path Quality Indicator | 路径质量指示 | N9 |
Rel-19在GTP-U中引入了标准化的延迟测量Extension Header，允许在gNB、I-UPF和PSA UPF之间进行精确的端到端延迟测量：
这与PFCP的QoS Monitoring机制形成闭环——GTP-U提供数据面的延迟测量，PFCP将结果传递给控制面进行策略决策。
为支持URLLC的双连接冗余传输场景，Rel-19新增了Redundancy Tag Extension Header：
GTP-U Header (Rel-19):
+---+---+---+---+---+---+---+---+
| Ver | PT | E | S | PN | EX | ...
+---+---+---+---+---+---+---+---+
| Message Type = 255 (G-PDU) |
+---+---+---+---+---+---+---+---+
| TEID (Tunnel Endpoint ID) |
+---+---+---+---+---+---+---+---+
| GTP-U Sequence Number |
+---+---+---+---+---+---+---+---+
| Extension Header: |
| - Delay Measurement (Type=X) |
| - Redundancy Tag (Type=Y) | <-- Rel-19新增
| R-SN | P-ID | D-R |
+---+---+---+---+---+---+---+---+
| Payload (User Data) |
+---+---+---+---+---+---+---+---+
Rel-19最大的架构改进之一是实现了从终端到用户面的端到端信令闭环。以下以URLLC场景为例展示三大协议如何协同工作：
图表 4
Rel-18 vs Rel-19协议能力对比：
| 能力维度 | Rel-18 | Rel-19 |
|---|---|---|
| QoS监控粒度 | Per QoS Flow | Per SDF（细粒度） |
| 延迟测量精度 | 毫秒级 | 亚毫秒/纳秒级 |
| 抖动/丢包监控 | 不支持 | 原生支持 |
| 冗余传输 | 上层实现 | GTP-U原生支持 |
| NTN定时器适配 | 基础扩展 | 全面扩展+自适应 |
| 按需注册 | 不支持 | 新增5GMM子状态 |
| TSC时间同步 | 基础5G时钟 | gPTP深度集成 |
| UPF节能 | 不支持 | PFCP控制休眠 |
对于运营商而言，Rel-19协议增强的部署需要考虑以下关键因素：
SMF侧： - 需要升级PFCP协议栈以支持新增IE（Enhanced QoS Monitoring、Multi-Path等） - QoS策略引擎需要支持更细粒度的SDF级监控策略 - 与PCF的接口（N7）需要同步增强以支持新的QoS参数传递
UPF侧： - 数据面需要支持纳秒级时间戳打标能力——这对UPF的硬件/NIC提出了更高要求 - 冗余消除功能需要维护状态表，对UPF内存和CPU有额外消耗 - TSC时钟同步需要UPF支持gPTP协议栈
AMF侧： - 需要根据接入类型（地面/卫星）动态选择NAS定时器配置 - 需要支持On-Demand Registration相关的5GMM状态机扩展
| 参数 | 推荐配置（URLLC场景） | 推荐配置（NTN场景） |
|---|---|---|
| QoS Monitoring周期 | 100ms-1s | 5s-30s |
| Delay阈值 | 1ms-5ms | 50ms-500ms |
| Jitter阈值 | 0.1ms-1ms | 10ms-100ms |
| 周期性注册定时器 | 标准值 | 60min-360min |
| NAS T3510定时器 | 5s | 30s-60s |
三大协议在Rel-19中的增强并非孤立进行，而是与多个配套规范紧密关联：
| 规范编号 | 关联内容 |
|---|---|
| TS 23.501 V19.x | 5G系统架构Stage 2，定义QoS监控、TSC、多路径的策略框架 |
| TS 23.502 V19.x | 5G系统流程Stage 2，定义PDU Session建立、QoS监控流程 |
| TS 29.500 V19.x | SBI设计原则 |
| TS 29.502 V19.x | SMF Services（Nsmf），连接NAS和PFCP的桥梁 |
| TS 38.415 V19.x | NG-RAN用户面协议（PDU Session User Plane Protocol），与GTP-U的接口 |
| TS 29.565 V19.x | TSCTSF Services，时间敏感通信的服务化接口 |
| TS 33.501 V19.x | 5G安全架构，NAS安全增强的基础 |
Q1: Rel-19的PFCP增强型QoS监控与Rel-17的基础QoS监控有什么本质区别？
A: Rel-17引入的QoS监控仅支持上下行包延迟的周期性测量，且粒度为Per QoS Flow。Rel-19的核心升级在于三个方面：一是监控粒度细化到Per SDF级别，可以针对同一QoS Flow内的不同业务流分别监控；二是新增了抖动（Jitter）和丢包率（Packet Loss Rate）的监控维度；三是引入了阈值触发报告机制，UPF不再只是周期性上报，还可以在检测到QoS指标越限时主动上报。这使得SMF能够更快速地感知网络状态变化并做出策略调整。
Q2: 现网SMF/UPF如何从Rel-18升级到Rel-19？需要全部升级吗？
A: 不需要全部升级。PFCP协议设计上保持了后向兼容性——所有新增IE都是可选的。建议采用渐进式升级策略：首先升级SMF以支持新的QoS监控策略下发，然后逐步升级UPF以支持增强型监控能力。在SMF判断对端UPF版本时，可通过PFCP Association Establishment过程中的UP Function Features IE进行能力协商。对于NTN NAS定时器扩展，仅需升级AMF即可，与UPF无关。
Q3: GTP-U的Redundancy Tag对UPF的性能有什么影响？
A: 冗余消除功能要求UPF为每个PDU Session维护一个冗余消除状态表，记录已接收的R-SN（Redundancy Sequence Number）。对于高吞吐量的URLLC场景（如工业控制），这意味着UPF需要额外的内存和CPU开销。实际部署中建议：(1) 仅对有冗余传输需求的PDU Session启用该功能；(2) UPF使用DPDK或SmartNIC加速冗余消除处理；(3) 设置合理的R-SN老化定时器，避免状态表无限增长。
Q4: On-Demand Registration与传统Periodic Registration有什么区别？
A: 传统Periodic Registration要求UE定期发送Registration Request以保持注册状态，适合始终在线的智能手机场景。On-Demand Registration是Rel-19针对低频次通信设备（如Ambient IoT、NTN覆盖间隙中的UE）引入的新机制：UE注册后可进入"按需"状态，在该状态下周期性注册定时器可以设得很长（数十分钟到数小时），且允许网络在UE有数据传输需求时才"激活"其注册状态。这显著减少了空口信令开销，特别适合卫星物联网场景。
Q5: Rel-19的TSC时钟同步对UPF有什么特殊硬件要求？
A: Rel-19要求UPF参与gPTP（generalized Precision Time Protocol）时钟分发，这意味着UPF需要：(1) 支持硬件时间戳打标（IEEE 1588v2兼容的NIC），精度要求达到亚微秒级；(2) 运行gPTP协议栈以与TSN网络的时间源同步；(3) 支持PFCP下发的时钟漂移测量功能。对于使用x86通用服务器的云化UPF，建议配备支持PTP的网卡（如Intel XXV710或Mellanox ConnectX-5及以上），并使用Linux内核的PTP Hardware Clock（PHC）子系统。
本文由「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 等场景全覆盖。
