# 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场景的适配调整： | 定时器 | 地面网络默认值 | NTN场景调整 | 规范章节 | |--------|---------------|------------|---------| | T3510 (Registration) | 6s | 可扩展至200s | TS 24.501 §5.5.1.2 | | T3502 (Registration retry) | 12min | 可扩展至180min | TS 24.501 §5.5.1.3 | | T3517 (Service Request) | 5s | 可扩展至200s | TS 24.501 §5.6.1 | | T3525 (TAU) | 12min | 可扩展至210min | TS 24.501 §5.5.3 |  > *图表 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-17 IE数量 | Rel-18 IE数量 | |---------|------|------|:------------:|:------------:| | PDR | Packet Detection Rule | 报文检测与分类 | 18 | 22 | | FAR | Forwarding Action Rule | 报文转发动作 | 10 | 14 | | BAR | Buffering Action Rule | 报文缓存动作 | 5 | 6 | | QER | QoS Enforcement Rule | QoS策略执行 | 8 | 12 | | URR | Usage Reporting Rule | 用量统计上报 | 12 | 16 | | **MAR** | **MBS Action Rule** | **组播广播动作** | **N/A** | **新增4** | 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： | 新增IE | 功能描述 | 应用场景 | |--------|---------|---------| | **Gate Status per QoS Flow** | 按QoS Flow粒度控制门控状态 | URLLC业务的精确流量控制 | | **QoS Monitoring Request** | 请求UPF进行QoS监控并上报 | 端到端时延监控 | | **Enhanced Gate Control** | 增强的门控能力，支持partial gate | 差分服务场景 | | **Alternative QoS Profile** | 备选QoS配置文件 | QoS降级/升级的快速切换 | | **Packet Rate for UL/DL** | 分别设置上下行包速率限制 | 非对称流量控制 | **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对其进行了增强： | 特性 | Rel-17 | Rel-18 | |------|--------|--------| | 时间戳精度 | 1μs | 100ns | | 测量方向 | 仅下行 | 上下行双向 | | 测量点 | UPF-to-UPF | UPF-to-UPF, UPF-to-gNB | | 上报方式 | 仅PFCP | PFCP + GTP-U内嵌 | | 主动监控 | 不支持 | 支持周期性探测包 | **增强的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） | 扩展头类型值 | 名称 | 引入版本 | 功能 | |:----------:|------|:------:|------| | 0x00 | No More Extension Headers | Rel-15 | 标记扩展头链结束 | | 0x01 | Long PDCP PDU Number | Rel-15 | 携带长PDCP序号 | | 0x02 | Packet Recovery Status | Rel-15 | NR重复检测 | | 0x03 | UL Delivery Status | Rel-15 | 上行投递状态 | | 0x40 | PDU Session Container | Rel-15 | PDU Session控制信息 | | 0x41 | PDCP PDU Number (short) | Rel-15 | 短PDCP序号 | | 0x42 | UL QoS Monitoring | Rel-17 | 上行QoS监控时间戳 | | 0x43 | DL QoS Monitoring | Rel-17 | 下行QoS监控时间戳 | | 0x44 | Enhanced QoS Monitoring | Rel-18 | 增强QoS监控（双向） | | 0x45 | QoS Monitoring Report | Rel-18 | QoS监控结果内嵌上报 | | 0x46 | User Plane Encryption | Rel-18 | 用户面加密信息 | | 0x85 | Xn RAN Container | Rel-16 | Xn切换RAN信息 | --- ## 五、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扩展**： | HTTP Header | 功能 | 引入版本 | |-------------|------|:--------:| | `3gpp-Sbi-Target-apiRoot` | 目标API根地址 | Rel-15 | | `3gpp-Sbi-Routing-Binding` | 路由绑定指示 | Rel-16 | | `3gpp-Sbi-Binding` | 通信绑定指示 | Rel-16 | | `3gpp-Sbi-Nf-Set-Id` | NF Set标识 | Rel-17 | | `3gpp-Sbi-Producer-Id` | 生产者实例标识 | Rel-17 | | `3gpp-Sbi-Slice-Info` | **切片感知路由信息** | **Rel-18** | | `3gpp-Sbi-Resource-Priority` | **资源优先级指示** | **Rel-18** | | `3gpp-Sbi-Timeout` | **请求超时控制** | **Rel-18** | **`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协议升级部署路径 | 阶段 | 升级内容 | 优先级 | 风险等级 | |------|---------|:------:|:-------:| | Phase 1 | SBI Binding增强 + NRF优化 | 高 | 低 | | Phase 2 | PFCP QER/URR增强 | 高 | 中 | | Phase 3 | GTP-U QoS Monitoring增强 | 中 | 低 | | Phase 4 | NAS NTN/RedCap适配 | 视业务需求 | 中 | | Phase 5 | PFCP MBS (N4mb) | 视业务需求 | 高 | ### 7.2 关键配置参数建议 **PFCP Session Establishment中的QER配置**（NTN场景）： ``` QER: QER 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 Features`IE是关键的版本协商载体——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 等场景全覆盖。