5G协议栈PFCP与NAS信令增强深度解析：从QoS监控到NTN卫星接入

随着3GPP Release 18（5G-Advanced第一个版本）的冻结和Release 19的完成，5G协议栈迎来了自Rel-15以来最大规模的一次信令协议升级。其中，PFCP协议（TS 29.244） 引入了面向每QoS Flow的精细化QoS监控框架，NAS协议（TS 24.501） 全面适配了非地面网络（NTN）卫星接入，SBI服务化接口（TS 29.500/29.501） 在HTTP/2通信模型上持续深化，而GTP-U（TS 29.281） 的扩展头机制也在为XR、边缘计算等新场景提供支撑。

本文将深入解读这四大协议栈的关键增强，从规范条文到工程实践，全景呈现5G-Advanced协议层的演进脉络。

一、PFCP协议演进：从粗粒度到Per-QoS Flow精细化管控

1.1 架构全景：PFCP在5GC中的位置

PFCP（Packet Forwarding Control Protocol）是5G核心网中SMF与UPF之间的控制面协议，承载在N4参考点上。它负责将SMF的会话管理策略转化为UPF的具体数据包处理规则。

图表 1

Rel-18中PFCP最核心的演进是引入了SRR（Session Reporting Rule）和QoS Monitoring per QoS Flow Control Information IE，使SMF能够对每个QoS Flow的时延、拥塞、数据速率进行独立监控，而不再局限于整个PDU Session级别的统计。

1.2 Per QoS Flow QoS Monitoring框架

TS 29.244 V18.x Section 5.39定义了全新的QoS Flow级QoS监控框架。该框架的核心思想是：SMF通过PFCP Session Establishment/Modification消息向UPF下发SRR规则，SRR中包含一个或多个QoS Monitoring per QoS Flow Control Information IE，每个IE指定：

• 需要监控的QFI（QoS Flow Identifier）
• 请求监控的QoS参数类型（时延/拥塞/数据速率）
• 报告频率（Event Triggered或Periodic）
• 阈值与最小等待时间

图表 2

1.3 四大监控参数详解

Rel-18/19 PFCP定义了四种可监控的QoS参数，每种对应不同的Feature Flag：

Packet Delay监控是最复杂也最关键的特性。UPF通过在下行GTP-U数据包的PDU Session Container扩展头中插入时间戳（QMP flag = 1），RAN收到后在上行方向回传UL/DL delay值，UPF据此计算端到端时延。具体机制参见TS 29.244 Section 5.24.4.3：

The UPF shall select one or more downlink payload packets pertaining to every requested QoS flow(s) whenever available or create one or more dummy downlink GTP-U packets (i.e. G-PDU messages without a T-PDU)... and insert the time stamp, and set the QoS Monitoring Packet (QMP) flag to "1".

当没有实际业务数据时，UPF会构造dummy GTP-U packet（不含T-PDU的G-PDU），用于维持时延测量。

1.4 GTP-U Path QoS Monitoring

除Per-QoS Flow监控外，TS 29.244 Section 5.24.5还定义了Per GTP-U Path级别的QoS监控。其核心区别在于：

GTP-U Path监控通过发送Echo Request消息并测量RTT来估算传输时延。UPF计算packet delay = RTT/2 + UPF内部处理时间，用于评估N3/N9等接口的传输质量。

1.5 UPF SBI事件暴露：Nupf_EventExposure

Rel-18引入的一个重要架构变革是UPF可以直接通过SBI接口向NEF/AF报告QoS监控事件，而不再必须经过SMF中转。TS 29.244 Section 5.40和TS 29.564定义了Nupf_EventExposure服务。

这一机制通过SRR中的Direct Reporting Information IE控制：

• 仅包含Event Notification URI → UPF直接上报给NEF/AF
• 同时设置DUPL flag = 1 → UPF同时上报给SMF和NEF/AF
• 不包含该IE → UPF仅上报给SMF（传统行为）

Feature Flag为DRQOS（Direct Reporting of QoS monitoring events）和UPSBIES（UPF Event Subscription via Service Based Interface）。

图表 3

工程意义：直接上报路径大幅降低了QoS监控事件的传递时延，对于URLLC、XR等低时延场景至关重要。同时减轻了SMF的信令处理负担。

1.6 新增关键IE一览

二、NAS协议演进：NTN卫星接入的全面适配

2.1 NTN对NAS协议的根本性挑战

非地面网络（NTN）引入了数百毫秒甚至秒级的传播时延，这对5G NAS协议的设计产生了深远影响。传统的NAS定时器（如T3510=15s、T3511=10s）在GEO卫星场景下（往返时延约540ms）几乎不可用。

TS 24.501 V19.x Section 4.23专门定义了卫星NG-RAN接入的NAS协议适配，核心包括：

1. 扩展NAS定时器
2. 多TAC处理
3. PLMN地理围栏
4. 卫星能力禁用/启用机制

2.2 扩展NAS定时器机制

TS 24.501 Section 4.23.3定义了针对不同卫星轨道类型的NAS定时器适配规则：

For 5GS mobility management via a satellite NG-RAN cell the UE shall apply the value of the applicable NAS timer indicated in table 10.2.1 for access via a satellite NG-RAN cell. The applied NAS timer values are based on the current satellite NG-RAN access RAT type determined based on information from lower layers.

关键设计点：

AMF通过Registration Accept消息中的扩展定时器参数通知UE适用的定时器值。SMF在会话管理时也通过类似机制适配5GSM定时器（Section 4.23.4）。

If the use of extended NAS timer for access via a satellite NG-RAN cell is indicated by the AMF (see TS 23.501 and TS 23.502), the SMF shall calculate the value of the applicable NAS timer indicated in table 10.3.2 for access via a satellite NG-RAN cell.

2.3 卫星多TAC处理

卫星波束覆盖范围远大于地面基站，一个卫星小区可能广播多个TAC（Tracking Area Code）。TS 24.501 Section 4.23.5定义了UE的TAC选择规则：

UE TAC选择优先级：
1. 属于当前注册区域的TAC（优先）
   → 进一步优先选择在"Allowed TAI"列表中且不在"Forbidden TAI"列表中的
2. 不属于任何禁止列表的TAC
3. 任意TAC（最后选择）

这一机制确保了卫星场景下UE不会因频繁的TAU（Tracking Area Update）而消耗过多信令资源。

2.4 PLMN地理围栏机制

NTN引入了全新的5GMM Cause #78 "PLMN not allowed to operate at the present UE location"。TS 24.501 Section 4.23.2定义了UE维护的"PLMNs not allowed to operate at the present UE location"列表，每个条目包含：

• PLMN Identity
• 接收到Cause #78时的地理位置（如果已知）
• UE实现相关的距离阈值
• 关联的定时器

这一机制解决了卫星覆盖跨越国界时可能违反当地电信监管要求的问题。当AMF判定UE当前位置不允许该PLMN运营时，下发Cause #78，UE存储该条目直到：

• 定时器超时
• 成功注册到该PLMN（非紧急服务）
• UE移动到足够远的地理位置

2.5 卫星能力禁用/启用

TS 24.501 Section 4.9.4定义了UE禁用/启用卫星NG-RAN能力的机制：

Disable of the satellite NG-RAN capability shall only be performed when the UE is in 5GMM-IDLE mode. When disabling the satellite NG-RAN capability, the UE: may disable the NR NTN access capability; shall memorize the identity of the PLMN where the satellite NG-RAN capability was disabled.

UE可选择性禁用NTN能力，并记忆禁用时的PLMN。这一机制适用于UE在有良好地面覆盖时节省卫星搜索功耗的场景。

2.6 GNSS定位时延对NAS的影响

TS 24.501 Section 5.1.1的一个重要NOTE：

In a satellite NG-RAN access, a GNSS fix time in lower layers can delay transmission of an initial UL NAS message by up to 100 seconds (GNSS cold state).

GNSS冷启动定位可延迟初始NAS消息发送达100秒，这意味着在NTN场景下，NAS定时器的设计必须考虑这个额外时延。这也是扩展定时器如此关键的原因之一。

三、SBI服务化接口演进：HTTP/2通信模型深化

3.1 SBI协议栈架构

TS 29.500定义了5G SBI的技术实现框架，其协议栈自下而上为：

┌─────────────────────────────────┐
│  3GPP NF Service (JSON/OpenAPI) │  ← 应用层
├─────────────────────────────────┤
│  HTTP/2 (RFC 9113)              │  ← 传输层
├─────────────────────────────────┤
│  TLS (RFC 8446)                 │  ← 安全层
├─────────────────────────────────┤
│  TCP                            │  ← 传输协议
└─────────────────────────────────┘

3.2 自定义HTTP Header的体系化扩展

Rel-18/19中SBI最显著的演进是自定义HTTP Header的大量扩展。TS 29.500 Section 5.2.3定义了完整的3gpp-Sbi-* Header族：

这些Header支撑了SCP（Service Communication Proxy）的间接通信模型，使SCP能够在不修改消息体的前提下执行NF发现、选择、路由等操作。

3.3 SCP间接通信模型

TS 29.500 Section 6.10定义了两种间接通信模式：

Model A：SCP已知于NF（SCP Known to the NF） - NF显式配置SCP地址 - NF向SCP发送请求时携带目标NF的apiRoot - 适用于NF部署规模较小的场景

Model B：SCP未知于NF（SCP Unknown to the NF） - NF不知道SCP的存在 - 通过DNS或网络配置将流量导向SCP - 适用于大规模部署，NF无需感知SCP

SCP支持Delegated Discovery（委托发现）和Without Delegated Discovery（无委托发现）两种模式：

3.4 过载控制与负载控制

TS 29.500 Section 6.3/6.4定义了SBI的过载控制和负载控制机制：

过载控制通过3gpp-Sbi-Oci Header传递：

3gpp-Sbi-Oci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; 
              Period-of-Validity: 120s; 
              Overload-Reduction-Metric: 25%; 
              SCP-FQDN: scp1.example.com

负载控制通过3gpp-Sbi-Lci Header传递：

3gpp-Sbi-Lci: Timestamp: "Tue, 04 Feb 2020 08:49:37 GMT"; 
              Load-Metric: 25%; 
              SCP-FQDN: scp1.example.com

两者的Scope粒度可以是：NF-Instance、NF-Set、NF-Service-Instance、NF-Service-Set、Callback-URI、SCP-FQDN或SEPP-FQDN。

3.5 SBI安全机制

SBI安全基于OAuth 2.0框架，TS 29.500 Section 13参考TS 33.501。关键要素：

1. 传输层安全：TLS用于PLMN内部（无其他安全措施时强制启用）
2. 应用层授权：OAuth 2.0 Client Credentials Grant（RFC 6749）
3. 跨PLMN安全：SEPP（Security Edge Protection Proxy）通过N32接口实现
4. CCA（Client Credentials Assertion）：Rel-18新增，用于SCP间接通信场景的NF认证

四、GTP-U协议演进：扩展头与新场景适配

4.1 GTP-U扩展头体系

TS 29.281定义的GTP-U扩展头机制是5G用户面的核心灵活性来源。扩展头的"Next Extension Header Type"字段中的Bits 7-8定义了处理规则：

4.2 PDU Session Container扩展头

PDU Session Container（扩展头类型0x85）是Rel-15引入、Rel-18/19大幅增强的关键扩展头。它承载在N3/N9接口的GTP-U数据包中，功能包括：

• QoS Flow Identifier（QFI）标识
• QoS Monitoring相关参数（QMP flag、时间戳、DL/UL delay）
• PDU Set Information（Rel-18新增，用于XR场景）
• End of Data Burst标记（Rel-18新增）

TS 29.281 Section 5.2.2.7对此扩展头的使用场景进行了定义：

A G-PDU message with this extension header may be sent without a T-PDU, e.g. when the G-PDU message is used as a dummy GTP-U packet for QoS Monitoring per QoS flow... where the PDU Session Container contains QoS Monitoring related parameters.

4.3 End Marker机制的演进

End Marker（GTP-U消息类型0xFE）在Rel-18中增加了对PDU Session Container扩展头的支持：

End marker packets sent over data forward tunnels in 5GS, for data forwarding between 5GS and EPS, shall be sent with the PDU Session Container extension header including the Qos Flow Identifier of one of the QoS flows mapped to the same E-RAB.

这一增强确保了5GS与EPS互操作场景下，End Marker能正确标识QoS Flow，避免数据转发过程中的QoS信息丢失。

4.4 NR RAN Container扩展头

NR RAN Container（扩展头类型0xC0）用于X2-U、Xn-U和F1-U接口，承载NG-RAN内部的数据转发信息。Rel-18增强了其内容，支持Dual Connectivity场景下的QoS Flow转移：

For QoS Flows transferred to and from Secondary RAN Node in Dual Connectivity, end marker packets shall be sent over old tunnel for the transferred QoS flows without the Qos Flow Identifier included.

五、协议栈协同：端到端QoS监控的数据面闭环

上述四大协议的增强并非孤立存在，而是构成了一个端到端的QoS监控闭环：

图表 4

这一闭环的关键数据元素在各协议层之间的流转关系如下：

六、现网部署与工程实践

6.1 UPF升级考量

对于UPF的Rel-18升级，需要重点关注以下Feature Flag的协商：

1. QFQM：Per QoS Flow Per UE Packet Delay监控——需要UPF支持高精度时间戳和dummy packet生成
2. GPQM：Per GTP-U Path QoS监控——需要UPF支持GTP-U Echo Request/Response的时延测量
3. DRQOS：直接QoS监控上报——需要UPF支持SBI协议栈（HTTP/2 + JSON）
4. UPSBIES：UPF SBI事件订阅——需要UPF部署完整的SBI服务端

关键配置建议：

• Measurement Period建议不小于100ms（避免过于频繁的PFCP Session Report）
• Minimum Wait Time建议设置为Measurement Period的2-3倍
• Event Triggered模式的Packet Delay Threshold应根据业务类型设置（URLLC: 5-10ms, eMBB: 30-50ms）
• 启用DRQOS时需要确保UPF到NEF/AF的SBI可达性

6.2 NTN NAS定时器配置建议

注意：GNSS冷启动可能引入高达100秒的额外时延，定时器配置应预留足够余量。

6.3 SCP部署注意事项

1. Delegated Discovery模式：适合NF规模较大、NRF压力高的场景，但增加了SCP的复杂度
2. Max Forward Hops：建议配置为3-5跳，防止SCP级联导致的路由环路
3. 过载控制：SCP应支持Oci和Lci Header的生成与转发，配合NF实现全链路过载保护
4. OAuth Token缓存：SCP在Delegated Discovery模式下需缓存NRF颁发的Access Token，建议TTL设置为5-10分钟

6.4 Rel-18→Rel-19升级路径

七、规范关联与依赖关系

常见问题

Q: PFCP的Per QoS Flow QoS监控和传统的URR（Usage Reporting Rule）有什么区别？

A: URR关注的是资源用量统计（流量字节数、时长、事件数），主要用于计费和配额控制。Per QoS Flow QoS监控（通过SRR）关注的是实时性能指标（包时延、拥塞度、数据速率），主要用于QoS保障和SLA监控。两者在PFCP Session中独立配置，URR通过Create/Update URR IE下发，SRR通过Create/Update SRR IE下发。一个PDR可以同时关联URR和SRR。

Q: UPF如何在没有业务数据时保持QoS时延监控？

A: UPF会构造dummy GTP-U packet（G-PDU without T-PDU），携带PDU Session Container扩展头中的时间戳和QMP flag。这些dummy packet在中间UPF（I-UPF）处会被正常转发（不剥除扩展头），但在RAN侧不会被发送给UE。这一机制确保了即使在没有实际业务数据时，UPF与RAN之间的时延测量也能持续进行。

Q: NTN场景下，UE如何知道当前应使用哪个NAS定时器值？

A: UE通过底层获取当前接入的卫星NG-RAN RAT类型（NR-LEO/NR-MEO/NR-GEO），然后根据TS 24.501 Table 10.2.1/Table 10.3.1中对应的定时器值进行适配。AMF同样根据底层指示的卫星类型，通过Registration Accept消息下发适配后的定时器值。NAS定时器值在NAS过程开始时计算一次，过程中不重新计算。

Q: SCP的Delegated Discovery和Without Delegated Discovery在实际部署中如何选择？

A: 如果网络中NF实例较多（如多个UPF、多个SMF），且NRF是性能瓶颈，建议使用Delegated Discovery——SCP代替NF查询NRF，减少NRF负载。但代价是SCP需要维护完整的NF发现能力。如果NF数量可控，或NF有特定的NF选择需求（如基于负载、地理位置），建议使用Without Delegated Discovery——NF自行查询NRF获取候选列表，SCP仅做消息路由。两种模式可以在同一网络中共存，不同NF可以配置不同的通信模式。

Q: UPF直接上报QoS监控事件到NEF/AF时，如何保证安全性？

A: 直接上报路径通过TS 29.564定义的Nupf_EventExposure服务实现，该服务遵循标准SBI安全框架：传输层使用TLS加密，应用层使用OAuth 2.0进行授权。SMF在PFCP Session Establishment时通过Direct Reporting Information IE将NEF/AF的Notification URI下发给UPF，UPF使用该URI发送事件通知。Notification URI通常由NEF在订阅QoS监控事件时提供，确保只有经过授权的NF才能接收事件通知。

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