3GPP Release 18作为5G-Advanced的首个标准版本，Release 19作为其演进延续，对5G系统控制面和用户面的核心信令协议进行了系统性增强。这不是简单的参数扩展——从PFCP会话管理机制到NAS注册流程优化，从GTP-U扩展头定义到SBI服务化接口演进，每一个协议层的变革都深刻影响着网络架构的部署灵活性和运营效率。
本文聚焦TS 29.244（PFCP）、TS 24.501（5GS NAS）、TS 29.281（GTP-U）以及SBI系列规范，深度解读Rel-18/19在这些协议层面的具体变化、设计动机和部署影响。
PFCP（Packet Forwarding Control Protocol）是SMF与UPF之间N4接口的控制面协议，承担PDU Session级别的会话管理、QoS策略执行、流量报告和用户面事件通知等关键功能。在5G控制面/用户面分离（CUPS）架构中，PFCP是连接控制面决策和用户面执行的唯一桥梁。
┌──────────────────────────────────────────────────────────────────────────┐
│ PFCP在5G架构中的协议栈位置 │
├──────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ SBI/HTTP2 ┌─────────┐ SBI/HTTP2 ┌─────────┐ │
│ │ AMF │◄──────────────►│ SMF │◄──────────────►│ PCF │ │
│ └─────────┘ └────┬────┘ └─────────┘ │
│ │ │ N4/PFCP │
│ N1/N2 NAS/NGAP │ │
│ │ ┌─────┴──────┐ │
│ ┌────┴────┐ │ PFCP协议层 │ │
│ │ (R)AN │ │ ┌────────┐ │ │
│ │ gNB │ │ │会话管理│ │ │
│ └────┬────┘ │ │节点管理│ │ │
│ │ N3/GTP-U │ │负载控制│ │ │
│ ┌────┴────┐ │ │QoS监控│ │ │
│ │ UPF │◄───────────────│ │事件报告│ │ │
│ └────┬────┘ N4/PFCP │ └────────┘ │ │
│ │ N6 └────────────┘ │
│ ┌────┴────┐ │
│ │DN/Internet│ │
│ └─────────┘ │
└──────────────────────────────────────────────────────────────────────────┘
Release 18在TS 29.244 V18.x中引入了多项重要增强，核心围绕URLLC可靠性提升、QoS监控细粒度化、以及多UPF场景下的会话管理优化。
Rel-18引入了更精细的QoS监控机制。在Rel-17已有的基础上，新增了对包延迟测量（Packet Delay Measurement）和包丢失率监控的PFCP级支持：
PACKET_DELAY触发类型，当包延迟超过门限时UPF主动上报
图表 1
Rel-18完善了URLLC场景下基于双连接（Dual Connectivity）的端到端冗余用户面路径的PFCP支持。关键变化包括：
Redundant Transmission Parameters IE，包含冗余传输的使能标志和去重参数PFCP Session Report中的Duplicate Packet Detection信元来上报重复包检测状态| IE名称 | IE Type | Rel-17状态 | Rel-18变化 |
|---|---|---|---|
| Requested QoS Monitoring | 167 | 基础定义 | 扩展DL/UL Packet Delay Threshold字段 |
| QoS Monitoring Report | 138 | 基础报告 | 新增per-Flow延迟统计和丢包计数 |
| Usage Reporting Rule | 84 | 事件触发 | 新增PACKET_DELAY触发类型 |
| Redundant Transmission Parameters | — | 不存在 | 新增IE，含使能标志和去重参数 |
| Apply Action | 51 | 基础定义 | 新增DUPL（复制）和DROP（丢弃冗余包）动作 |
| PFCP Session Report | — | 基础格式 | 新增Duplicate Packet Detection信元 |
Rel-18在PFCP Session Modification流程中增加了对UPF重定位场景的优化。当需要将PDU Session从一个UPF迁移到另一个UPF时，引入了以下改进：
UPF Relocation Indication标志，SMF可以指示UPF这是迁移操作的一部分Data Forwarding Tunnel Info IE允许在旧UPF和新UPF之间预建立GTP-U数据转发隧道Release 19（已于2025年12月冻结）在PFCP层面进一步深化了以下方向：
Rel-19引入了对Ambient IoT（环境物联网）设备的管理能力。这类无源/半无源设备通过反向散射通信与网络交互，PFCP需要支持极轻量的会话管理：
Ambient IoT Session Parameters IE：包含设备类型、能量收集方式、通信模式等参数Rel-19为PFCP引入了AI/ML相关的参数传递能力：
AI/ML Traffic Handling Parameters IE：SMF可以向UPF下发基于AI/ML模型的流量分类规则Rel-19引入的Personal IoT Network架构要求PFCP支持PIN元素的会话管理：
图表 2
TS 24.501定义了5G系统的NAS层协议，涵盖5GS Mobility Management（5GMM）和5GS Session Management（5GSM）两大子层。NAS消息在UE和AMF之间传递，是5G系统移动性管理和会话管理的核心信令载体。
Rel-18对5GS Registration流程进行了多项优化，目标是减少信令交互次数和注册延迟：
Registration type = Incremental registration，允许UE仅更新发生变化的部分信息，而非全量注册UE Radio Capability ID在NAS层的传递，避免重复上报无线能力信息Rel-18为非地面网络（NTN）引入了多项NAS级扩展：
Satellite Information IE：包含卫星类型（GEO/LEO/MEO）、覆盖区域标识NTN Timing Advance IE：针对卫星大时延场景的特殊时间提前量TA List for NTN，允许为NTN UE分配更大的TA List| NAS消息/IE | Rel-17 | Rel-18变化 |
|---|---|---|
| Registration Request | 5种类型 | 新增Incremental Registration类型 |
| Satellite Information IE | 不存在 | 新增，含卫星类型/覆盖区域 |
| NTN Timing Advance | 不存在 | 新增，针对卫星大时延 |
| UE Radio Capability ID | Rel-16引入 | NAS层传递机制增强 |
| TA List for NTN | 不存在 | 新增，允许更大TA范围 |
| 5GSM Cause Values | 59个 | 新增NTN和QoS监控相关cause值 |
Rel-18针对RedCap（Reduced Capability）终端引入了NAS层简化机制：
Rel-19需要为Ambient IoT设备设计极简的NAS信令：
Rel-19引入了更多节能相关的NAS机制：
图表 3
GTP-U（GPRS Tunnelling Protocol - User Plane）在5G系统中用于N3（gNB-UPF）和N9（UPF-UPF）接口的用户面数据隧道传输。每个GTP-U包包含TEID（Tunnel Endpoint Identifier）用于标识隧道。
Rel-18在TS 29.281中引入了新的GTP-U扩展头类型：
PDU Session Container扩展头，携带结束原因指示在冗余用户面路径场景中，GTP-U层承担了关键的复制和去重功能：
Rel-18对ATSSS功能的GTP-U支持进行了增强：
| GTP-U特性 | Rel-17 | Rel-18变化 |
|---|---|---|
| Extension Header Types | 0x00-0xC0 | 新增QoS Monitoring相关扩展 |
| End Marker | 基础定义 | 新增PDU Session Container扩展头 |
| QoS Flow Identifier | 通过PDU Session Container传递 | 扩展延迟测量时间戳 |
| URLLC Redundancy | Rel-16基础定义 | 完善双隧道复制/去重机制 |
| ATSSS Support | 基础Steering | 新增MPTCP Proxy扩展头 |
| N3/N9接口 | 标准GTP-U | 优化大时延链路（NTN）传输参数 |
Rel-19在GTP-U层面的演进主要围绕以下方向：
Service-Based Interface（SBI）是5GC Service-Based Architecture的核心，所有NF之间的交互通过RESTful HTTP/2 API实现。SBI的设计哲学是将网络功能分解为可独立调用、可灵活组合的服务。
Rel-18增强了NF Discovery和NF Selection机制：
NF Service Load参数，允许NRF在选择NF时考虑负载均衡新增NF Set概念增强，支持跨厂商NF实例的协同
Nnrf_NFDiscovery API扩展：
complex-query支持更复杂的多条件组合查询Rel-18对SBI的事件通知机制进行了统一化改进：
图表 4
Rel-18对SBI底层HTTP/2传输进行了多项优化：
Rel-19开始为6G时代的SBI演进做准备：
Rel-19为Personal IoT Network定义了新的SBI接口：
| SBI接口 | Rel-17 | Rel-18变化 | Rel-19变化 |
|---|---|---|---|
| Nnrf_NFDiscovery | 基础查询 | +complex-query, +geo-filter | 语义化查询研究 |
| Nnrf_NFManagement | 基础注册 | +NF Service Load, +NF Set增强 | 继续优化 |
| Nsmf_EventExposure | 基础事件 | +Event Aggregation | +AI/ML事件 |
| Namf_Communication | 基础流程 | +Incremental Reg支持 | +PIN Element Mgmt |
| Npcf_PolicyAuthorization | 基础授权 | QoS监控策略增强 | +Ambient IoT策略 |
| 新增API | — | — | PIN Gateway Control |
在5G核心网中，SBI接口和PFCP接口需要紧密协同。一个典型的场景是QoS策略的端到端执行：
Rel-18/19的增强使得这条跨层链路更加高效：增强的QoS Monitoring IE使UPF能提供更精确的延迟测量数据，Event Aggregation减少了SMF-PCF之间的通知消息量，而新的GTP-U扩展头则确保了用户面和控制面测量的一致性。
| 升级维度 | 注意事项 |
|---|---|
| PFCP版本协商 | UPF应支持PFCP Association Setup中的版本协商，确保与Rel-17/18 SMF的兼容 |
| IE向后兼容 | 新增IE的Criticality应设为ignore或notify，避免旧版本SMF/UPF处理失败 |
| NAS消息长度 | Rel-18扩展的NAS消息（如NTN参数）可能导致消息超长，需检查N1/N2接口MTU |
| SBI API版本 | NF应支持多版本API共存，Rel-18新增参数应设计为Optional |
| GTP-U扩展头 | 旧UPF可能不识别新扩展头类型，需确保扩展头的Next Extension Header字段正确处理 |
| 冗余路径部署 | 双UPF冗余场景要求SMF支持两个并行PFCP Session，需验证SMF的N4 Session容量规划 |
| 本规范 | 关联规范 | 关联点 |
|---|---|---|
| TS 29.244 (PFCP) | TS 23.501 | 系统架构定义，PDU Session管理框架 |
| TS 29.244 (PFCP) | TS 29.512 | PCF策略到PFCP规则的映射 |
| TS 24.501 (NAS) | TS 23.502 | NAS流程与整体信令流程的对应 |
| TS 24.501 (NAS) | TS 38.331 | NAS/RRC层交互 |
| TS 29.281 (GTP-U) | TS 38.415 | NR PDU Session用户面协议 |
| TS 29.281 (GTP-U) | TS 29.244 | PFCP与GTP-U隧道的关联 |
| SBI系列 | TS 29.500 | SBI通用技术原则 |
| SBI系列 | TS 29.510 | NRF服务定义 |
┌─────────────────────────────────────────────────────────────────┐
│ 5G-Advanced 信令协议演进全景 (Rel-18 → Rel-19) │
├──────────────┬──────────────────────┬───────────────────────────┤
│ 协议层 │ Rel-18 关键变化 │ Rel-19 新增变化 │
├──────────────┼──────────────────────┼───────────────────────────┤
│ PFCP │ • Enhanced QoS Mon │ • Ambient IoT Session │
│ (N4接口) │ • 冗余UP路径 │ • AI/ML Traffic IE │
│ │ • 多UPF迁移优化 │ • PIN Element支持 │
│ │ • URLLC去重机制 │ • 批量Session管理 │
├──────────────┼──────────────────────┼───────────────────────────┤
│ NAS │ • 增量注册 │ • Ambient IoT适配 │
│ (N1接口) │ • NTN参数扩展 │ • 能量感知信令 │
│ │ • RedCap简化流程 │ • eDRX增强 │
│ │ • 扩展TA List │ • PIN设备NAS │
├──────────────┼──────────────────────┼───────────────────────────┤
│ GTP-U │ • QoS Mon扩展头 │ • Ambient IoT简化封装 │
│ (N3/N9) │ • End Marker增强 │ • MBS组播隧道优化 │
│ │ • ATSSS扩展 │ • 低开销传输研究 │
│ │ • URLLC双隧道 │ │
├──────────────┼──────────────────────┼───────────────────────────┤
│ SBI │ • 增强NF Discovery │ • 语义化API │
│ (服务化) │ • 事件聚合通知 │ • PIN SBI接口 │
│ │ • HTTP/2优化 │ • Service Mesh探索 │
│ │ • 负载感知选择 │ • 面向6G准备 │
└──────────────┴──────────────────────┴───────────────────────────┘
Q: PFCP的增强QoS监控与RAN侧的QoS监控有何区别和协同关系？
A: RAN侧的QoS监控主要在空口（Uu接口）进行，测量的是UE到gNB之间的延迟和丢包；而PFCP级的QoS监控在N3/N9接口的UPF侧进行，测量的是gNB到UPF以及UPF到UPF之间的核心网段延迟。两者协同使用可以实现端到端的QoS可观测性。SMF可以通过PFCP Session Report获取核心网段延迟，结合从AMF获取的RAN侧QoS监控结果，形成完整的端到端QoS画像，进而触发PCF的策略调整。Rel-18的关键改进是使这两个监控点能够使用统一的时间戳参考框架，确保测量结果的一致性。
Q: 在现网中如何从Rel-17平滑升级到Rel-18 PFCP？
A: 升级策略建议采用渐进式：首先升级SMF以支持PFCP V18版本，但通过PFCP Association Setup中的版本协商保持与旧版UPF的兼容。新增的IE（如Requested QoS Monitoring扩展字段）在PFCP消息中的Criticality应设置为"ignore"，使旧UPF能安全忽略不认识的字段。在新UPF部署后，可通过PFCP Node-level的Feature Query确认对端支持的Rel-18特性列表，然后逐步启用增强功能。需特别注意UPF容量规划——冗余用户面路径场景下PFCP Session数量翻倍，对UPF的会话管理能力提出更高要求。
Q: Rel-18 NAS的增量注册（Incremental Registration）具体减少了多少信令开销？
A: 传统全量Registration Request消息大约需要200-300字节（含所有5GMM参数和5GSM参数），而增量注册仅携带变化的参数，典型场景下消息大小可缩减60%-80%。例如，当UE仅需要更新TAI而不改变其他参数时，增量注册请求可能仅需50-80字节。但需注意：增量注册需要AMF维护完整的UE Context，且首次注册仍必须使用全量注册。此外，如果AMF因重启丢失了UE Context，会拒绝增量注册并要求UE发起全量注册。
Q: SBI的Event Aggregation通知机制如何工作？有何性能收益？
A: Event Aggregation允许Producer NF将多个相关事件聚合到一条HTTP通知消息中发送。例如，SMF可以向AMF发送一条聚合通知，同时报告PDU Session建立完成和QoS监控门限越限事件，而非分别发送两条独立通知。具体机制是通过扩展的Nsmf_EventExposure_Notify请求体，使用JSON数组格式包含多个event对象。性能收益取决于事件密度——在高事件频率场景（如大量URLLC Session同时建立）下，通知消息量可减少40%-60%，显著降低HTTP连接数和NF处理负载。配置时需设置合理的聚合窗口（如50ms-200ms）以平衡实时性和效率。
Q: Rel-19的Ambient IoT对PFCP/NAS协议的影响有多大？
A: 影响深远但方式特殊。Ambient IoT设备（尤其是无源类型）通常不具备运行完整NAS/PFCP协议栈的能力。3GPP的方案是让Ambient IoT设备的信令通过Interrogator（读写器/中继节点）代为完成——读写器使用标准NAS与AMF通信、标准PFCP与UPF交互，而Ambient IoT设备本身使用完全不同的物理层和轻量MAC层。因此PFCP侧主要新增的是批量Session管理（一个Interrogator可能管理成百上千个Ambient IoT设备）和Ambient IoT Session Parameters IE；NAS侧则主要由Interrogator代为处理，TS 24.369为Ambient IoT定义了专门的协议。这种代理架构意味着核心网PFCP/NAS实现需要支持大规模、轻量化的会话管理，对SMF和UPF的并发处理能力提出了新挑战。
本文由「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 等场景全覆盖。
