5G PCF SM Policy Association 与 PCC 规则下发信令全链拆解

一、为什么要把 PCF 单独拎出来拆

在 5G 核心网里，SMF 负责会话的生命周期管理，UPF 负责用户面转发，但"这条业务流到底该走什么 QoS、要不要限速、按什么费率计费、哪个应用被检测到后该不该提升 QoS"——这些策略决策权全部集中在 PCF（Policy Control Function）。SMF 本身不持有任何策略，它只是 PCF 决策的"执行者"。

PCF 与 SMF 之间的 N7 接口，是整个 5G PCC（Policy and Charging Control）框架最核心、信令最密集的一段。它通过 Npcf_SMPolicyControl 这个 SBI 服务，在 PDU 会话建立、修改、释放的每一个关键节点进行策略交互。理解这段信令，是理解 5G 差异化 QoS、计费、AF 业务触发的基础。

本文聚焦 TS 23.502 Section 4.3.2.2.1（PDU Session Establishment）、TS 23.503 Section 6.3（PCC 规则定义）、TS 29.512（Npcf_SMPolicyControl 服务定义）、TS 29.513（PCC 信令流与 QoS 参数映射） 中的具体机制，逐步拆解 SM Policy Association 的建立、PCC 规则的四元操作、QoS Flow 绑定、以及 PCF/SMF 双向触发的策略更新流程。

二、SM Policy Association 生命周期总览

SM Policy Association 是 PCF 与 SMF 之间围绕一个 PDU 会话建立的一段"策略上下文关联"。它的生命周期严格绑定 PDU 会话：会话建立时创建、会话存续期间可被双向修改、会话释放时删除。三段式操作对应 Npcf_SMPolicyControl 的三个核心服务操作：

sequenceDiagram
    participant UE
    participant SMF
    participant PCF
    participant UPF
    Note over SMF,PCF: ① 建立 SM Policy Association
    SMF->>PCF: POST /npcf-smpolicycontrol/v1/policies<br/>(SmPolicyContextData)
    PCF->>PCF: 查UDR订阅数据 + 匹配PCC规则
    PCF-->>SMF: 201 Created (SmPolicyDecision)<br/>PCC规则/QoS决策/计费决策/请求触发器
    Note over SMF,UPF: 绑定QoS Flow → N4下发 → 会话建立完成
    Note over SMF,PCF: ② 双向修改（PCF主动 / SMF请求）
    PCF->>SMF: POST {notificationUri}/update<br/>(SmPolicyNotification)<br/>add/mod/remove PCC规则
    SMF->>PCF: PUT/PATCH /policies/{polAssoId}<br/>(SmPolicyUpdateContextData)
    PCF-->>SMF: 200 OK (SmPolicyDecision)
    Note over SMF,PCF: ③ 删除 SM Policy Association
    SMF->>PCF: DELETE /policies/{polAssoId}
    PCF-->>SMF: 204 No Content

设计上把"策略关联"独立成一个资源（/policies/{polAssoId}），是为了让 PCF 状态与会话状态解耦：PCF 只要持有 polAssoId，就能在任何时刻主动推送策略变更（UpdateNotify 回调），而不必等 SMF 来问。这正是 5G 区别于 4G PCRF"Gx 接口"轮询式交互的关键演进——SBI 的资源化建模天然支持服务端推送。

三、SM Policy Association 建立：SmPolicyContextData → SmPolicyDecision

3.1 建立时机

在 UE 发起的 PDU 会话建立流程（TS 23.502 Section 4.3.2.2.1）中，SMF 收到 AMF 转发的 PDU Session Establishment Request 后，依次完成：UDM 订阅数据获取（SMF Selection / DNN 上下文）、SMF 选择、UPF 选择，然后在向 UE 发送 PDU Session Establishment Accept 之前，必须先建立 SM Policy Association——因为默认 QoS、Session AMBR、计费键这些信息只有 PCF 能给。

3.2 请求 IE：SmPolicyContextData

SMF 通过 POST /npcf-smpolicycontrol/v1/policies 发起建立，请求体 SmPolicyContextData 携带的 IE 是 PCF 做策略决策的全部输入：

3.3 响应 IE：SmPolicyDecision

PCF 综合 UDR 订阅数据 + 本地策略逻辑 + AF（经 Npcf_PolicyAuthorization，TS 29.514）下发的业务需求，返回 SmPolicyDecision。这是整个 PCC 框架的"决策聚合体"，它不是单一规则，而是一组解耦的决策对象：

graph TD
    A[SmPolicyDecision] --> B[pccRules<br/>PCC规则集合]
    A --> C[sessionRules<br/>会话级规则]
    A --> D[qosDecs<br/>QosData决策对象]
    A --> E[chgDecs<br/>ChargingData计费对象]
    A --> F[trafContDecs<br/>TrafficControlData流量控制]
    A --> G[usaDecs<br/>UsageMonitoringData用量监控]
    A --> H[policyCtrlReqTriggers<br/>策略控制请求触发器]
    A --> I[conRuleRefs<br/>条件规则引用]
    B -->|refQosData| D
    B -->|refChgData| E
    B -->|refTcData| F
    B -->|refUmData| G

这里有一个精巧的设计：PCC 规则本身不内嵌 QoS/计费参数，而是通过 refQosData、refChgData 等引用 ID 指向独立的决策对象。一条 QosData 可以被多条 PCC 规则复用，避免了参数冗余，也使得"改 QoS 不必重传整条规则"成为可能——只需在 UpdateNotify 里下发一个新的 qosDecs 引用即可。这种引用解耦是 TS 23.503 Section 6.3 与 6.4 的核心设计。

3.4 PCC 规则结构（TS 23.503 Section 6.3）

单条 PCC 规则的关键属性：

四、PCC 规则的四元操作

TS 23.503 Section 6.1.3 定义了对 PCC 规则的四种操作，理解它们的区别是排错的关键：

• Install（安装）：新增一条规则到 SMF，规则进入 ACTIVE 状态并立即生效（绑定 QoS Flow）。
• Remove（移除）：删除规则，释放关联的 QoS Flow（若是最后一条引用该 Flow 的规则）。
• Activate（激活）：将已存在但 INACTIVE 的规则置为 ACTIVE，重新绑定 QoS Flow。
• Deactivate（去激活）：将 ACTIVE 规则置为 INACTIVE，但不删除，保留包过滤器配置，仅释放 QoS Flow 资源。

去激活而不删除的意义在于：典型场景是 AF（如视频服务器）临时挂起某业务流，QoS Flow 释放以节省空口资源，但过滤器仍在，AF 恢复时只需 Activate 即可重建，避免重新走规则匹配。UpdateNotify 中 pccRules 数组每条规则带一个 op 字段（add/mod/remove，激活去激活通过 ruleStatus 表达）。

五、QoS Flow 绑定机制

PCF 下发的是"业务数据流（SDF）级"的策略，而空口/N4 上真正承载的是"QoS Flow"。SMF 必须把 PCC 规则绑定到一个 QoS Flow 上——这是 TS 29.513 Section 4.3.x 的核心动作。绑定逻辑：

1. 取 PCC 规则引用的 QosData（5QI、ARP）。
2. 若是 Non-GBR 规则，优先绑定到默认 QoS Flow（5QI=5/9 等）。
3. 若是 GBR 规则（5QI 带 GBR 特性），建立专用 QoS Flow。
4. 包过滤器（flowInformation）下发给 UE 作为 QoS Rule，下发给 UPF 作为 PDR 的 SDF Filter。

如果 SMF 发现没有任何 QoS Flow 能承载该规则（例如专用 Flow 建立失败），会回带 NO_QOS_FLOW_BOUND 错误（见 TS 29.512 OpenAPI 错误码），PCF 据此重试或回退策略。

六、PCF 发起的策略更新：UpdateNotify 信令流

这是 PCC 框架最动态的部分——业务在运行中，AF 通过 Npcf_PolicyAuthorization（N5/Npcf接口，TS 29.514）告诉 PCF"这个视频流需要保证 10Mbps"，PCF 据此主动向 SMF 推送 PCC 规则变更。完整流程（TS 29.513 Section 4.3，TS 29.512 Section 4.2.3）：

sequenceDiagram
    participant AF
    participant PCF
    participant SMF
    participant RAN
    participant UE
    AF->>PCF: PUT /npcf-policyauthorization/v1/app-sessions<br/>{flowInfo, qosReq: 10Mbps GBR}
    PCF->>PCF: 匹配PCC规则 + 生成qosDecs
    Note over PCF: 主动下发（无需SMF请求）
    PCF->>SMF: POST {notificationUri}/update<br/>SmPolicyUpdateData<br/>pccRules: add(GBR规则)<br/>qosDecs: 新QosData
    SMF->>SMF: 绑定专用QoS Flow(新建)
    SMF->>RAN: PDU Session Resource Modify<br/>(新GBR QoS Flow)
    RAN->>UE: RRC Reconfiguration
    SMF->>PCF: 200 OK<br/>(执行结果反馈)
    Note over SMF,PCF: 若QoS Flow建立失败
    SMF->>PCF: 200 OK 带policyCtrlReqTriggers<br/>QOS_FLOW_FAILED

关键点：PCF 推送用的是回调——建立关联时 SMF 把自己的 notificationUri 注册给 PCF，后续 PCF 直接 POST 到这个 URI（TS 29.512 Section 4.2.3 Npcf_SMPolicyControl_UpdateNotify）。SmPolicyUpdateData 中的 pccRules 数组就是变更增量，配合 qosDecs/chgDecs 增量下发，SMF 做差分应用。注意 policyCtrlReqTriggers 中的 QOS_FLOW_FAILED：当 SMF 无法建立所需 QoS Flow（空口拒绝、资源不足），会回带此触发器通知 PCF，PCF 可降级策略——这是 R15/R16 增强的重要闭环。

七、SMF 发起的策略修改：请求触发器机制

并非所有更新都由 PCF 主动发起。很多场景是会话状态变化触发的，SMF 需要回头问 PCF"情况变了，策略要不要调整"。但 SMF 不能无脑上报——PCF 在建立关联时通过 policyCtrlReqTriggers 告诉 SMF"哪些条件发生时才来找我"。TS 23.503 Section 6.2 定义的典型触发器：

SMF 触发修改用 PUT/PATCH /policies/{polAssoId}，请求体 SmPolicyUpdateContextData 带上触发的 trigger 列表及关联上下文（如检测到的应用 ID、新 IP、失败原因等），PCF 返回新的 SmPolicyDecision。状态转换：

stateDiagram-v2
    [*] --> 建立: POST /policies
    建立 --> 稳态: SmPolicyDecision下发
    稳态 --> PCF主动更新: UpdateNotify<br/>(AF触发/定时/策略变更)
    稳态 --> SMF请求修改: 触发器命中<br/>PUT/PATCH
    PCF主动更新 --> 稳态: SMF执行完成
    SMF请求修改 --> 稳态: PCF返回新决策
    稳态 --> 删除: DELETE<br/>(会话释放)
    删除 --> [*]

八、抓包识别与故障排错

8.1 抓包识别

N7 是 SBI HTTP/2 接口，在抓包中识别要点： - URL 路径：/npcf-smpolicycontrol/v1/policies 是建立；.../policies/{polAssoId} 带 ID 的是修改/删除；.../update 回调是 PCF 主动推送。 - 方法：POST 建立、PUT/PATCH 修改、DELETE 释放、POST 到 SMF 的 notificationUri 是 UpdateNotify。 - Content-Type：application/json，体里搜 "pccRules"、"qosDecs"、"policyCtrlReqTriggers" 可快速定位决策内容。 - 在 Wireshark 中可用 http2.headers.authority contains "pcf" 或 json.value contains "SmPolicyDecision" 过滤。

8.2 常见故障点

1. SM Policy Association 建立失败（4xx）：通常是 SmPolicyContextData 缺字段（如缺 subscribedDnn）或 supi 在 UDR 查不到订阅。看 PCF 返回的错误码与 ProblemDetails。
2. PCC 规则下发但 QoS Flow 未建立：SMF 侧 NO_QOS_FLOW_BOUND，多半是 QosData 的 ARP/5QI 配置与空口能力不符，或专用 GBR Flow 在 RAN 被拒（看 NGAP PDU Session Resource Setup Response 失败原因）。
3. UpdateNotify 不生效：检查建立时 SMF 是否正确注册了 notificationUri；回调 404 多为 URI 过期或 SMF 容灾迁移后未更新。
4. 策略不更新：触发器未命中——确认 policyCtrlReqTriggers 是否包含对应 trigger，例如 AF 改 QoS 不生效，需确认 PCF 推送时 SmPolicyUpdateData 的 pccRules 是否带新 qosDecs 引用。
5. 计费键缺失：refChgData 引用的 chgDecs 未在决策中下发，导致 SMF 无法生成计费规则，CHF 侧会看到流量无计费记录。

九、设计意图总结

把 PCC 规则与 QoS/计费/流量控制决策引用解耦，让"规则集"与"参数集"正交，是 5G PCC 相比 4G Gx 的本质进步：增量下发、参数复用、动态激活成为一等公民。而 SBI 资源化建模 + 回调推送机制，使 PCF 能在会话任意时刻主动介入，支撑了 AF 驱动的动态 QoS、ADC 触发的策略变更、漫游场景的差异化控制。理解 polAssoId 资源的生命周期与四元操作，是排障 N7 一切问题的起点。

常见问题

Q1：PCC 规则的 Install 与 Activate 有什么区别？ A：Install 是把一条新规则加入 SMF 规则集并生效；Activate 是把已存在但处于 INACTIVE 的规则重新激活。区别在于规则是否已存在于 SMF——去激活保留了包过滤器配置只释放 QoS Flow，激活则重建 Flow，常用于业务临时挂起/恢复场景，避免重新走规则匹配与下发。

Q2：PCF 主动下发策略为什么用回调而不是 SMF 轮询？ A：建立 SM Policy Association 时 SMF 把自己的 notificationUri 注册给 PCF，PCF 在策略变更时直接 POST 到该 URI（UpdateNotify）。这避免了 SMF 周期性询问造成的信令浪费与延迟，是 SBI 服务端推送的标准模式，也比 4G Gx 的 CCA 被动应答更高效。

Q3：policyCtrlReqTriggers 不配置会怎样？ A：如果 PCF 在 SmPolicyDecision 中不下发任何 trigger，SMF 默认不会因任何会话状态变化主动找 PCF——即使用户漫游、IP 变化、应用被检测到，SMF 也不会上报。结果是策略僵化，无法动态适配。实际部署中至少应配置 PLMN_CHANGE、UE_IP_CHANGE、QOS_FLOW_STATUS 等基础触发器。

Q4：NO_QOS_FLOW_BOUND 错误如何排查？ A：该错误表示 SMF 找不到合适的 QoS Flow 绑定 PCC 规则。排查顺序：①看 PCC 规则引用的 QosData 的 5QI 是否为合法值；②若是 GBR 5QI，检查 ARP 是否允许抢占、GBR/MBR 是否合理；③看空口 NGAP PDU Session Resource Setup/Modify Response 是否因资源不足拒绝专用 Flow 建立；④确认 RAN 是否支持该 5QI（异厂商 RAN 对部分 GBR 5QI 支持不一致）。

Q5：漫游场景下 SM Policy Association 建在哪一侧？ A：Home-Routed 漫游时，PDU 会话锚点 SMF 在 HPLMN，SM Policy Association 建在 HPLMN PCF 与 H-SMF 之间；VPLMN 的 V-SMF 不与 PCF 直接交互，仅做 N9 转发。Local Breakout 漫游时，V-SMF 可与 V-PCF 建立关联，但 V-PCF 需遵循漫游协议，HPLMN 策略经 UDR 同步或经 H-PCF 协商。

参考来源

1. 3GPP TS 29.512 — Npcf_SMPolicyControl Service — Section 4.2.2/4.2.3/4.2.4（建立/UpdateNotify/修改）
2. 3GPP TS 29.513 — 5G PCC Signalling Flows & QoS Parameter Mapping — Section 4 PCC 信令流
3. 3GPP TS 23.503 — Policy and Charging Control Framework — Section 6.3 PCC规则、6.2请求触发器、6.1.3规则操作
4. 3GPP TS 23.502 — System Procedures — Section 4.3.2.2.1 PDU会话建立
5. ShareTechnote — 5G Core SMF — SM Policy Association 流程图解
6. free5GC Blog — Mapping PCC Rules into Session Rules — 规则映射实现分析
7. Nokia Documentation — PCF-based Policy Management — PCC 规则增删改机制

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