# 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` 的三个核心服务操作： ```mermaid sequenceDiagram participant UE participant SMF participant PCF participant UPF Note over SMF,PCF: ① 建立 SM Policy Association SMF->>PCF: POST /npcf-smpolicycontrol/v1/policies
(SmPolicyContextData) PCF->>PCF: 查UDR订阅数据 + 匹配PCC规则 PCF-->>SMF: 201 Created (SmPolicyDecision)
PCC规则/QoS决策/计费决策/请求触发器 Note over SMF,UPF: 绑定QoS Flow → N4下发 → 会话建立完成 Note over SMF,PCF: ② 双向修改（PCF主动 / SMF请求） PCF->>SMF: POST {notificationUri}/update
(SmPolicyNotification)
add/mod/remove PCC规则 SMF->>PCF: PUT/PATCH /policies/{polAssoId}
(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 做策略决策的全部输入： | IE 名称 | 说明 | 策略用途 | |---------|------|---------| | `supi` | 订阅永久标识符 | 查 UDR 订阅策略数据 | | `pduSessionId` | PDU 会话 ID | 关联标识 | | `dnn` | 数据网络名 | 匹配 DNN 级策略 | | `snssai` | 切片标识 | 切片级差异化策略 | | `pduSessionType` | IPv4/IPv6/Ethernet | 决定地址族相关规则 | | `ipv4Address` / `ipv6AddressPrefix` | UE IP | 后续 AF 反向查找 | | `ueLocation` | 用户位置信息 | 区域级策略 | | `ratType` | 接入类型 | NR/非3GPP差异化 | | `servingGuamiList` | 服务 AMF | 漫游/容灾 | | `peduSubscriptionId` | 订阅 ID | 关联订阅上下文 | | `subscribedDnn` / `subscribedSnssai` | 订阅的 DNN/S-NSSAI | 校验合规性 | ### 3.3 响应 IE：SmPolicyDecision PCF 综合 UDR 订阅数据 + 本地策略逻辑 + AF（经 `Npcf_PolicyAuthorization`，TS 29.514）下发的业务需求，返回 `SmPolicyDecision`。这是整个 PCC 框架的"决策聚合体"，它不是单一规则，而是一组**解耦的决策对象**： ```mermaid graph TD A[SmPolicyDecision] --> B[pccRules
PCC规则集合] A --> C[sessionRules
会话级规则] A --> D[qosDecs
QosData决策对象] A --> E[chgDecs
ChargingData计费对象] A --> F[trafContDecs
TrafficControlData流量控制] A --> G[usaDecs
UsageMonitoringData用量监控] A --> H[policyCtrlReqTriggers
策略控制请求触发器] A --> I[conRuleRefs
条件规则引用] 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 规则的关键属性： | 属性 | 作用 | |------|------| | `pccRuleId` | 规则唯一标识 | | `precedence` | 规则优先级，决定 SDF 检测顺序 | | `flowInformation` | 业务数据流包过滤器（5元组+方向） | | `refQosData` | 引用 QosData（5QI、ARP、GBR/MBR） | | `refChgData` | 引用计费键、计费方法 | | `refTcData` | 引用门控（gate open/close） | | `appFlowInfo` | 应用检测描述（用于 ADC） | | `ruleStatus` | ACTIVE / INACTIVE | ## 四、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）： ```mermaid sequenceDiagram participant AF participant PCF participant SMF participant RAN participant UE AF->>PCF: PUT /npcf-policyauthorization/v1/app-sessions
{flowInfo, qosReq: 10Mbps GBR} PCF->>PCF: 匹配PCC规则 + 生成qosDecs Note over PCF: 主动下发（无需SMF请求） PCF->>SMF: POST {notificationUri}/update
SmPolicyUpdateData
pccRules: add(GBR规则)
qosDecs: 新QosData SMF->>SMF: 绑定专用QoS Flow(新建) SMF->>RAN: PDU Session Resource Modify
(新GBR QoS Flow) RAN->>UE: RRC Reconfiguration SMF->>PCF: 200 OK
(执行结果反馈) Note over SMF,PCF: 若QoS Flow建立失败 SMF->>PCF: 200 OK 带policyCtrlReqTriggers
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 定义的典型触发器： | 触发器 | 触发条件 | 典型场景 | |--------|---------|---------| | `PLMN_CHANGE` | UE 漫游到新 PLMN | 漫游策略切换 | | `UE_IP_CHANGE` | UE IP 变化 | SSC 模式 2/3 重分配 | | `RES_ID_RELOCATION` | PSA 重定位 | SSC3 切换 | | `QOS_FLOW_STATUS` | GBR Flow 状态变化 | 业务流挂起/恢复 | | `RAT_TY_CHANGE` | 接入类型变化 | NR↔非3GPP切换 | | `REF_QOS_CHANGE` | 参考QoS变化 | 默认QoS调整 | | `UE_TIME_ZONE_CHANGE` | 时区变化 | 计费时段判定 | | `ACCESS_TYPE_CHANGE` | 3GPP↔非3GPP | 接入策略差异 | | `QOS_FLOW_FAILED` | QoS Flow建立失败 | 策略降级 | | `APP_DETECTION` | 应用被检测到 | ADC触发策略 | SMF 触发修改用 `PUT/PATCH /policies/{polAssoId}`，请求体 `SmPolicyUpdateContextData` 带上触发的 trigger 列表及关联上下文（如检测到的应用 ID、新 IP、失败原因等），PCF 返回新的 `SmPolicyDecision`。状态转换： ```mermaid stateDiagram-v2 [*] --> 建立: POST /policies 建立 --> 稳态: SmPolicyDecision下发 稳态 --> PCF主动更新: UpdateNotify
(AF触发/定时/策略变更) 稳态 --> SMF请求修改: 触发器命中
PUT/PATCH PCF主动更新 --> 稳态: SMF执行完成 SMF请求修改 --> 稳态: PCF返回新决策 稳态 --> 删除: DELETE
(会话释放) 删除 --> [*] ``` ## 八、抓包识别与故障排错 ### 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](https://www.3gpp.org/dynareport/29512.htm) — Section 4.2.2/4.2.3/4.2.4（建立/UpdateNotify/修改） 2. [3GPP TS 29.513 — 5G PCC Signalling Flows & QoS Parameter Mapping](https://www.3gpp.org/dynareport/29513.htm) — Section 4 PCC 信令流 3. [3GPP TS 23.503 — Policy and Charging Control Framework](https://www.3gpp.org/dynareport/23503.htm) — Section 6.3 PCC规则、6.2请求触发器、6.1.3规则操作 4. [3GPP TS 23.502 — System Procedures](https://www.3gpp.org/dynareport/23502.htm) — Section 4.3.2.2.1 PDU会话建立 5. [ShareTechnote — 5G Core SMF](https://www.sharetechnote.com/html/5G/5G_Core_SMF.html) — SM Policy Association 流程图解 6. [free5GC Blog — Mapping PCC Rules into Session Rules](https://free5gc.org/blog/20241113/20241113/) — 规则映射实现分析 7. [Nokia Documentation — PCF-based Policy Management](https://documentation.nokia.com/mag-c/24-3/books/cpf/pcf-based-policy-management.html) — 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 等场景全覆盖。