5G-Advanced 控制面协议栈演进：NAS/PFCP/GTP-U/SBI 从Rel-18到Rel-19的深度变革

引言：5G-Advanced协议层的系统性重构

3GPP Release 18标志着5G-Advanced的正式启航，Release 19则在此基础上进一步深化了控制面协议栈的演进。与Rel-15/16以架构创新为主不同，Rel-18/19的协议层变革呈现出精细化、场景化、智能化三大特征——NAS协议为NTN和RedCap设备量身定制新流程，PFCP引入MBS组播广播控制能力，GTP-U扩展头持续丰富以支持更精细的QoS监控，而SBI框架则朝着更高效的服务化通信方向演进。

本文将从工程师视角，深入剖析TS 24.501、TS 29.244、TS 29.281、TS 29.500四大核心规范在Rel-18/19中的关键变化，并结合现网部署给出实操建议。

一、整体架构：5G-Advanced控制面协议栈全景

在展开具体协议分析之前，先建立5G-Advanced控制面协议栈的整体视图。Rel-18/19的控制面协议栈变化并非孤立的点状更新，而是围绕几个核心场景进行的系统性适配：

图表 1

上图展示了5G-Advanced控制面协议栈的层次关系。本文聚焦的四个核心协议分别覆盖UE-to-Core（NAS）、SMF-to-UPF（PFCP）、UPF-to-UPF（GTP-U）、NF-to-NF（SBI）四条关键链路。

二、NAS协议增强（TS 24.501）：从地面到太空的信令适配

2.1 NTN场景下的NAS注册流程重构

Rel-17首次引入了NTN（Non-Terrestrial Network）支持，但在NAS层面的适配相对有限。Rel-18/19对TS 24.501进行了深层次的NTN信令适配，核心变化集中在以下方面：

PLMN选择机制增强：Rel-18新增了对卫星特定PLMN选择的支持。UE在NTN场景下需要考虑卫星的覆盖模式（地球固定小区 vs. 地球移动小区），NAS层新增了NTN-PLMN-Selection相关信息元素，允许UE根据卫星ephemeris（星历）数据预判可用PLMN。

注册请求中的NTN能力指示：Rel-18在Registration Request消息中引入了新的5GMM capability IE扩展，UE可以指示其是否支持： - 卫星接入模式（Satellite Access Mode） - 延迟容忍服务（Delay Tolerant Service） - NTN特定定时器值（NTN-specific timer values）

定时器适配：NTN场景下RTT（Round Trip Time）显著增大（LEO约20-40ms，GEO约540ms），Rel-18对以下NAS定时器进行了NTN场景的适配调整：

图表 2

2.2 RedCap设备的NAS简化流程

Rel-18引入的Reduced Capability（RedCap）NR设备在NAS层面也获得了专门的简化处理。RedCap设备（如工业传感器、可穿戴设备）通常具有低复杂度、低功耗的特点，TS 24.501 Rel-18为这类设备引入了以下优化：

简化注册类型：RedCap UE可以指示其设备类型（Device Type IE），网络据此可以： - 跳过不必要的NAS安全流程中的某些步骤 - 使用更长的周期性注册定时器（Periodic Registration Timer），减少信令开销 - 简化Service Request流程中的承载建立过程

5GSM会话管理简化：对于只需要单PDU Session的RedCap设备，Rel-18允许： - 在Registration Request中携带"Requested PDU Session"信息，将注册和会话建立合并 - 减少PDU Session Establishment流程中的交互轮次

2.3 Rel-19 NAS新特性前瞻

Rel-19在NAS协议层面的进一步增强方向包括：

• AI/ML模型分发信令支持：NAS层新增AI/ML相关的Information Element，用于终端与网络之间协商AI/ML能力
• Personal IoT Network（PIN）：支持设备到设备中继场景下的NAS注册和会话管理
• 增强的紧急服务：改进Emergency Registration流程，支持卫星紧急呼叫

三、PFCP协议演进（TS 29.244）：从N4到N4mb的跨越

3.1 PFCP协议核心机制回顾

PFCP（Packet Forwarding Control Protocol）是5G核心网SMF与UPF之间的控制面协议，定义在TS 29.244中。PFCP的核心设计包含两个层次：

• PFCP Association：SMF与UPF之间的关联级管理（Node-level）
• PFCP Session：每个PDU Session对应的会话级管理（Session-level）

PFCP Session通过五类规则（Rule）控制用户面行为：

Rel-18最显著的变化是新增了MAR（MBS Action Rule），用于支持5G Multicast/Broadcast Service（MBS）。

3.2 MBS组播广播控制：N4mb接口

Rel-17引入了5G MBS的基本框架（TS 23.247），Rel-18在TS 29.244中完整定义了N4mb接口的PFCP协议扩展。N4mb是MB-SMF（Multicast/Broadcast SMF）与MB-UPF（Multicast/Broadcast UPF）之间的控制接口。

MAR规则详解：

MAR（MBS Action Rule）是Rel-18为MBS场景全新设计的PFCP规则类型，其核心功能包括：

1. 组播分发控制：MB-UPF根据MAR规则将MBS数据通过组播/广播方式分发给下游节点
2. 多路径转发：同一MBS流量可以同时通过组播路径和单播路径（fallback）转发
3. 成员管理联动：MAR与PDR关联，当UE加入/离开MBS组时动态调整转发行为

MAR的核心IE包括：

MAR ID (唯一标识)
Member Operation (成员操作: Add/Remove/Modify)
Multicast Forwarding (组播转发参数)
Unicast Forwarding Fallback (单播回退参数)
MBS Session ID (MBS会话标识)

图表 3

3.3 QER增强：精细化的QoS控制

Rel-18对QER（QoS Enforcement Rule）进行了显著增强，新增了以下关键IE：

Alternative QoS Profile 是Rel-18引入的一个重要概念，它允许SMF在建立PFCP Session时预配置一个备选QoS配置。当UPF检测到主QoS Profile无法满足时（例如时延超限），可以自动切换到备选Profile，而无需等待SMF下发PFCP Session Modification。这一机制显著降低了QoS切换的时延。

3.4 URR增强：面向5G-Advanced的用量上报

Rel-18的URR增强主要体现在：

• 事件触发的用量上报：新增多种触发条件，如QoS Monitoring事件、包延迟超限等
• 多测量集：URR可以同时包含多个测量集（Measurement Set），分别统计不同维度的用量
• 时间粒度控制：支持更细粒度的上报周期控制，从秒级到小时级可配置

3.5 PFCP到SBI的演进趋势

一个值得关注的行业趋势是PFCP向SBI的演进探索。IEEE和学术界已有研究论文探讨将PFCP的控制面通信迁移到基于HTTP/2的Service-Based Interface上（参见Springer 2025年发表的 "Design and Evaluation of a Service-Based Interface for the Control of User Plane Functions"）。这一方向的核心动机包括：

1. 统一通信模型：当前5GC中，大部分NF间通信已基于SBI/HTTP/2，唯独SMF-UPF接口仍使用二进制PFCP协议
2. 云原生兼容性：RESTful API更易于与Kubernetes Service Mesh、API Gateway等云原生基础设施集成
3. 可观测性：HTTP/2通信天然支持更好的可观测性（tracing、metrics）

但这一迁移面临显著的性能挑战——PFCP作为二进制协议，在N4 Session数量巨大时的编解码效率远优于JSON/HTTP。因此，短期内PFCP仍是N4接口的主流选择，但SBI化是中长期演进方向。

四、GTP-U扩展头演进（TS 29.281）：用户面的精确控制

4.1 GTP-U扩展头在Rel-18的关键变化

GTP-U定义在TS 29.281中，其扩展头（Extension Header）机制是用户面控制的关键载体。Rel-18对GTP-U扩展头进行了多项增强：

新增加密扩展头：Rel-18为支持用户面安全（UP Security, TS 37.354）引入了新的加密扩展头类型。当UPF与UPF之间或UPF与gNB之间的用户面需要加密保护时，GTP-U包中携带加密扩展头，包含：

• 加密算法标识
• 密钥标识（Key ID）
• 序列号（用于重放保护）
• 加密后的负载数据

QoS Monitoring扩展头增强：

Rel-17引入了基本的QoS Monitoring能力（通过GTP-U扩展头携带时间戳），Rel-18对其进行了增强：

增强的PDU Session Container扩展头：

PDU Session Container是GTP-U中携带PDU Session相关控制信息的扩展头。Rel-18对其进行了以下增强：

• 支持新的QoS Flow Identifier（QFI）范围扩展
• 支持Reflective QoS的增强指示
• 支持Multiple QoS Flow在一个GTP-U包中的指示

4.2 GTP-U扩展头类型总览（Rel-18）

五、SBI框架增强（TS 29.500/29.501）：服务化通信的精细化

5.1 Binding机制的演进

SBI（Service-Based Interface）的技术实现在TS 29.500（Technical Realization of SBA）和TS 29.501（Principles and Guidelines for Services Definition）中定义。Rel-18对SBI的Binding机制进行了重要增强。

Binding是SBI中的核心概念，它决定了NF Consumer如何选择与NF Producer之间的通信绑定关系。Rel-18增强了Binding的维度：

Rel-17 Binding Levels： - NF Instance级别（绑定到特定NF实例） - NF Set级别（绑定到NF实例集合）

Rel-18新增Binding Levels： - NF Service级别（绑定到NF的特定Service Instance） - NF Service Set级别（绑定到NF Service实例集合） - Slicing-aware Binding（感知切片的绑定）

Slicing-aware Binding是Rel-18引入的关键特性，它允许NF Consumer在选择绑定目标时考虑S-NSSAI（Single Network Slice Selection Assistance Information）信息，确保服务请求被路由到正确的切片实例。

5.2 HTTP/2通信优化

Rel-18对SBI的HTTP/2通信进行了多项优化：

Custom HTTP Headers扩展：

3gpp-Sbi-Resource-Priority 的引入是一个重要的增强，它允许在拥塞场景下，高优先级的SBI请求（如Emergency Call相关的NF通信）可以优先被处理。这与TS 29.500中定义的Overload Control机制联动，提供更精细的拥塞管理能力。

5.3 NRF Service Discovery增强

Rel-18对NRF（Network Repository Function）的服务发现机制进行了增强：

• 条件化查询：支持更丰富的查询条件组合（如S-NSSAI + DNN + TA + NF Capacity的组合查询）
• 增量通知：NF Profile变化时，NRF可以发送增量更新通知（而非完整NF Profile），减少通知消息大小
• 偏好指示：NF Consumer可以在Discovery Request中携带偏好指示（如"prefer local NF"、"prefer low-latency NF"），NRF据此排序返回结果

5.4 面向Rel-19的SBI演进

Rel-19在SBI框架层面的进一步增强方向包括：

• HTTP/3/QUIC探索：评估HTTP/3（基于QUIC传输协议）在SBI中的应用可行性，以降低NF间通信延迟
• 服务网格集成：增强SBI与Kubernetes Service Mesh（如Istio）的兼容性
• 零信任架构：在SBI通信中引入更强的身份验证和授权机制

六、协议联调：端到端信令流程实例

为了展示上述协议增强如何在实际网络中协同工作，以下给出一个NTN场景下RedCap设备的PDU Session Establishment端到端信令流程：

图表 4

这个端到端流程展示了Rel-18/19协议增强的协同工作方式： 1. NAS层携带RedCap和NTN能力指示（TS 24.501增强） 2. SBI通信使用切片感知绑定路由到正确的NF实例（TS 29.500增强） 3. PFCP Session建立时配置NTN适配的QoS参数和备选QoS Profile（TS 29.244增强） 4. GTP-U携带增强的QoS Monitoring扩展头进行端到端延迟监控（TS 29.281增强）

七、现网部署与迁移建议

7.1 Rel-18协议升级部署路径

7.2 关键配置参数建议

PFCP Session Establishment中的QER配置（NTN场景）：

QER:
  QER ID: <unique_id>
  Gate Status: OPEN
  QoS Flow Identifier (QFI): 7
  Maximum Packet Rate (UL): 1000 pps     # NTN场景降低上限
  Maximum Packet Rate (DL): 2000 pps
  Alternative QoS Profile:               # Rel-18新增
    - Primary: GFBR=50ms, MDBR=10Mbps
    - Alternative: GFBR=200ms, MDBR=5Mbps # 卫星信号衰落时降级
  QoS Monitoring Request: ENABLED         # Rel-18增强
    - Reporting Period: 10s
    - Measurement: TWO_WAY_DELAY

SBI HTTP Header配置（切片感知绑定）：

HTTP/2 Headers:
  3gpp-Sbi-Slice-Info: {"s-nssai": {"sst": 1, "sd": "010203"}}
  3gpp-Sbi-Resource-Priority: HIGH
  3gpp-Sbi-Timeout: 30000
  3gpp-Sbi-Routing-Binding: {"bl": "NF-SET", "nf-set-id": "smf-set-1"}

7.3 协议兼容性注意事项

1. PFCP版本协商：Rel-18 UPF必须支持与Rel-17/16 SMF的向后兼容。PFCP Association Setup中的UP Function FeaturesIE是关键的版本协商载体——SMF应检查UPF报告的功能位图，仅使用UPF支持的功能。

2. GTP-U扩展头兼容性：新增的扩展头类型（如0x44-0x46）对于不支持它们的节点应标记为"comprehension not required"，确保向后兼容。

3. SBI API版本管理：Rel-18 SBI API应使用OpenAPI规范的版本号机制（如v1、v2），确保NF Consumer可以正确发现和使用兼容的API版本。

常见问题

Q: PFCP中的MAR规则和传统的FAR规则有什么本质区别？

A: FAR（Forwarding Action Rule）处理的是单播场景下的报文转发——一个PDR匹配的报文通过FAR确定转发目标（单个下一跳）。MAR（MBS Action Rule）专门为组播广播场景设计，一个MAR可以同时控制组播分发路径和单播回退路径。关键区别在于：FAR是"一对一"转发，MAR是"一对多"分发。此外，MAR与MBS Session ID关联，支持动态成员管理，这是FAR不具备的。

Q: 在现网中如何从Rel-17 PFCP平滑升级到Rel-18？

A: 推荐采用分阶段策略：（1）先升级UPF软件，确保支持Rel-18的UP Function Features位图中新增的功能指示；（2）SMF通过PFCP Association Setup阶段的版本协商自动适配——如果UPF报告支持Rel-18功能，SMF才使用新功能；（3）对于MBS功能，建议单独部署MB-SMF/MB-UPF实例，不影响现有单播业务。关键是要确保PFCP Node-level的Feature Bitmap正确配置和解析。

Q: SBI的切片感知绑定对现网NRF有什么影响？

A: 影响主要体现在三方面：（1）NRF的NF Profile数据模型需要扩展，增加S-NSSAI与NF实例的映射关系；（2）NRF的Discovery查询接口需要支持新的查询参数组合；（3）NRF的通知机制需要支持增量更新。这些变化是增量式的——不支持切片感知绑定的NF Consumer仍然可以正常工作，只是不会获得最优的绑定决策。建议优先升级NRF和核心SMF/AMF的SBI协议栈。

Q: GTP-U QoS Monitoring的精度提升对UPF硬件有什么要求？

A: Rel-18将QoS Monitoring时间戳精度从1μs提升到100ns，这意味着UPF需要具备纳秒级的时间戳能力。在硬件层面，通常需要：（1）支持PTP（IEEE 1588v2）硬件时间戳的网卡；（2）UPF软件需要使用硬件时间戳API而非系统时钟；（3）对于容器化部署，需要确保PTP时间同步信号能正确传递到容器内。在纯软件实现中，100ns精度难以保证，建议使用DPDK+硬件时间戳的方案。

Q: NAS NTN定时器扩展会不会导致地面网络的注册延迟增大？

A: 不会。NTN定时器扩展是可选的——仅当UE和网络都支持NTN且当前通过卫星接入时，才使用扩展后的定时器值。地面网络场景下，所有定时器保持原有的默认值。AMF在Registration Accept消息中携带的定时器值是根据当前接入类型动态确定的。对于同时支持地面和卫星接入的UE，网络切换时会自动调整定时器值。

本文由「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 等场景全覆盖。