<!-- title: 5G PCF PCC规则下发拆解 -->
<!-- domain: core-network -->

# 5G PCF 策略控制会话管理与 PCC 规则下发机制全链拆解

## 一、为什么 PCF 是 5GC 的"指挥中枢"

在 5G 系统（5GS）中，**策略与计费控制（Policy and Charging Control, PCC）** 是把"商业意图"翻译成"网络行为"的核心枢纽。无论是运营商的资费套餐、AF（应用功能）下发的低时延业务需求，还是网络切片的 SLA 保障，最终都要落到一个具体的网元——**PCF（Policy Control Function）** 上做决策，再以 **PCC 规则（PCC Rule）** 的形式下发到 SMF，由 SMF 翻译成 QoS Flow，最终在 UPF 与 (R)AN 上执行。

PCF 在架构上等价于 4G EPC 中的 PCRF，但有一个本质区别：5GC 全面采用 **SBI（Service Based Interface，基于服务的接口）**，PCF 对外暴露的是标准化 RESTful 服务，而非 4G 时代的 Diameter Gx 接口。这使得 PCF 的每一次策略决策，都是一次清晰的 HTTP/2 资源操作，可被云原生地编排、负载均衡和抓包分析。

本文聚焦 TS 23.502 §4.3.2.2.1（PDU 会话建立）中 PCF 的具体交互，结合 TS 29.513（Npcf_SMPolicyControl 服务）、TS 29.512（策略数据模型）、TS 23.503（PCC 架构）和 TS 23.501 §5.7.1（QoS Flow 绑定），把 **SM Policy Association 建立 → SmPolicyDecision 下发 → PCC 规则到 QoS Flow 的绑定执行** 这条全链路拆解到底。

## 二、PCC 架构与关键接口全景

5G 的 PCC 体系由控制面（PCF、SMF）与数据面（UPF）协同构成，PCF 通过两条核心服务对外提供策略：

| 服务（SBI） | 接口 | 消费者 | 规范 | 作用域 |
|------------|------|--------|------|--------|
| Npcf_SMPolicyControl | N7 | SMF | TS 29.513 | 会话级 QoS、门控、计费策略 |
| Npcf_AMPolicyControl | N15 | AMF | TS 29.514 | 接入与移动性策略（业务区限制、RFSP） |
| Npcf_BDTPolicyControl | N7 | SMF | TS 29.513 | 背景数据传送策略 |
| Npcf_PolicyAuthorization | N5/N30 | AF/NEF | TS 29.514 | AF 请求业务 QoS/门控授权 |

此外，PCF 还会通过 Nudr（UDR）获取签约策略数据，通过 Nudm_SDM 获取用户数据，通过 NEF/CHF 与外部交互。本文聚焦最核心的 **Npcf_SMPolicyControl（N7）**。

下图给出策略决策的来源与下发全景：

```mermaid
graph LR
    UDM[UDM<br/>签约策略] -->|签约数据| PCF
    AF[AF<br/>业务QoS需求] -->|N5/N30| PCF
    NEF[NEF<br/>第三方能力开放] -->|N30| PCF
    UDR[UDR<br/>策略数据存储] -->|Nudr| PCF
    CHF[CHF<br/>计费/配额] <-.计费关联.-> PCF

    PCF[PCF<br/>策略决策中心]
    PCF -->|N7 SBI<br/>SmPolicyDecision| SMF
    SMF -->|PCC Rule→QoS Flow绑定| UPF
    SMF -->|QoS规则下发N1| UE
    SMF -->|QFI/QoS参数NGAP| RAN[gNB]

    style PCF fill:#d4edda,stroke:#28a745,stroke-width:2px
    style SMF fill:#cce5ff,stroke:#007bff
    style UPF fill:#fff3cd,stroke:#ffc107
```

## 三、SM Policy Association 建立完整信令时序

SM Policy Association 是 SMF 与 PCF 之间围绕一个 PDU 会话建立的一个策略会话（association），生命周期与该 PDU 会话绑定。其建立时机嵌在 **PDU 会话建立流程（TS 23.502 §4.3.2.2.1）** 的第 6~7 步之间。完整时序如下：

```mermaid
sequenceDiagram
    autonumber
    participant UE
    participant AMF
    participant SMF
    participant PCF
    participant UPF
    participant RAN as gNB

    Note over UE,RAN: 前置：注册完成，UE发起PDU会话建立
    UE->>AMF: NAS PDU Session Establishment Request<br/>(DNN, S-NSSAI, Request Type)
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext<br/>(SUPI, DNN, S-NSSAI, PCF Id?)
    Note over SMF: SMF选择PCF（本地配置或NRF发现）
    SMF->>PCF: Npcf_SMPolicyControl POST /sm-policies<br/>(SUPI, DNN, S-NSSAI, IPv4, IPv6Prefix,<br/>SubscSessAmbr, notifUri, pdusessionid,<br/>subsDefQos, ipv4FrameRouteList)
    Note over PCF: PCF评估签约+运营商策略+AF订阅
    PCF->>UDR: Nudr_Query策略数据(可选)
    PCF-->>SMF: 201 Created + SmPolicyDecision<br/>(sessRules, pccRules, qosDecs,<br/>chgDecs, umDecs, policyCtrlReqTriggers)
    Note over SMF: SMF执行PCC Rule→QoS Flow绑定
    SMF->>UPF: N4 PFCP Session Establishment<br/>(PDR/FAR/QER/URR安装, 门控/限速/计费)
    SMF->>RAN: N2 PDU Session Resource Setup<br/>(PDU Session Res Setup List, QFI, QoS Flow parms)
    SMF->>AMF: N1 SM容器: PDU Session Establishment Accept<br/>(QoS Rules, Session AMBR)
    AMF->>UE: 转发 NAS 消息
    UE-->>AMF: 上行数据已可传输
    Note over SMF,PCF: 运行期：触发条件命中→SM Policy Update
    SMF->>PCF: POST /sm-policies/{id}/update<br/>(policyCtrlReqTriggers报告)
    PCF-->>SMF: SmPolicyUpdate / SmPolicyDecision
    Note over SMF,PCF: 网络侧主动变更→PolicyUpdateNotification
    PCF->>SMF: POST {notifUri}/update (callback)<br/>(更新/删除PCC规则)
    Note over SMF,PCF: 会话释放→删除关联
    SMF->>PCF: DELETE /sm-policies/{id}
    PCF-->>SMF: 204 No Content
```

### 逐步解析关键信息元素

**第 3 步 `POST /sm-policies`（SMF → PCF）** 是 SM Policy Association 建立的请求消息，其请求体为 `SmPolicyContext`，核心 IE 如下：

| IE（请求方向） | 含义 | 作用 |
|---------------|------|------|
| `supi` | 用户永久标识 | PCF 据此查 UDR/UDM 签约 |
| `pduSessionId` | PDU 会话标识 | 关联策略到具体会话 |
| `pduSessionType` | IPv4/IPv6/Ethernet | 影响计费与门控类型 |
| `dnn` | 数据网络名 | 决定 APN 级策略 |
| `snssai` | 网络切片标识 | 切片级策略匹配 |
| `ipv4Address` / `ipv6AddressPrefix` | UE IP | 计费、门控、监控绑定 |
| `subsSessAmbr` | 签约会话 AMBR | 默认 Session Rule 限速依据 |
| `subsDefQos` | 签约默认 QoS（5QI/ARP） | 默认 QoS Flow 的 QoS |
| `notifUri` | 回调 URI | PCF 主动推送策略变更用 |
| `altNotifIpv4/6Addrs` | 冗余回调地址 | SMF 集群冗余保障 |
| `subsPlmnVar` / `ratType` | PLMN/接入类型 | 漫游与异构接入差异化 |

**第 4 步 `SmPolicyDecision`（PCF → SMF）** 是整个策略下发机制的"灵魂"，其结构由 TS 29.512 定义，是一个组合对象，包含若干并列的策略元素集合。

## 四、SmPolicyDecision 数据结构深度拆解

SmPolicyDecision 并不是一张扁平的规则表，而是按"职责分离"原则拆成多个独立数组，SMF 再通过 `qosId`/`chgId`/`pccRuleId` 等引用键将它们组合使用。这种设计的好处是：QoS 参数、计费参数、门控参数可以独立更新而不必重传整个规则。

```mermaid
classDiagram
    class SmPolicyDecision {
        +assocId: string
        +sessRules: SessionRule[]
        +pccRules: PccRule[]
        +qosDecs: QosData[]
        +chgDecs: ChargingData[]
        +umDecs: UsageMonitoringData[]
        +policyCtrlReqTriggers: PolicyCtrlReqTrigger[]
        +qosFlowUsage: enum
        +ueIPv4Reserv / ueIPv6Reserv
    }
    class SessionRule {
        +policyRuleId
        +refQosData: qosId
        +refCondData
        +sessRulesFlags
        +authSessAmbr
        +authDefQos
    }
    class PccRule {
        +pccRuleId
        +refQosData: qosId
        +refChgData: chgId
        +refUmData: umId
        +refAccData
        +precedence: int
        +appRef
        +flowInfos: FlowInformation[]
        +urlCodec
        +gateStatus: OPEN/CLOSED
    }
    class QosData {
        +qosId
        +5qi: int
        +arp: ARP
        +maxbrUl/Dl: bit rate
        +gbrUl/Dl: bit rate
        +qnc: bool
        +priorityLevel
        +averWindow
        +maxDataBurstVol
    }
    class ChargingData {
        +chgId
        +ratingGroup
        +offLin / onLine: bool
        +meteringMethod
        +reportingLevel
    }

    SmPolicyDecision "1" o-- "*" SessionRule
    SmPolicyDecision "1" o-- "*" PccRule
    SmPolicyDecision "1" o-- "*" QosData
    SmPolicyDecision "1" o-- "*" ChargingData
    PccRule --> QosData : refQosData
    PccRule --> ChargingData : refChgData
    SessionRule --> QosData : refQosData
```

### PCC Rule 关键 IE 参数说明

PCC Rule（`PccRule`）是 SmPolicyDecision 中最核心的策略单元，下表逐一说明其关键字段：

| PCC Rule IE | 类型 | 含义与设计意图 |
|-------------|------|---------------|
| `pccRuleId` | string | 规则唯一标识，SMF/UPF 用作安装键 |
| `precedence` | int | **过滤匹配优先级**，值越小优先级越高；多个规则匹配同一流时取最高优先 |
| `refQosData` | qosId | 引用 QosData，提供 5QI/ARP/GBR/MBR |
| `refChgData` | chgId | 引用计费数据（计费键/评级组） |
| `refUmData` | umId | 引用使用量监控（流量配额） |
| `flowInfos` | list | **SDF 过滤器集合**（IP 5 元组：源/目的 IP、端口、协议），定义本规则管控的业务流 |
| `appRef` | AppId | 基于应用检测（ADC）匹配，无需精确 5 元组 |
| `gateStatus` | OPEN/CLOSED | **门控状态**，CLOSED 时 UPF 丢弃匹配分组 |
| `urlCodec` | string | URL 级别匹配（深度业务识别） |
| `ruleStatus` | ACTIVE/INACTIVE | 规则是否立即生效 |

**设计意图剖析**：5G 把 QoS、门控、计费三类参数从 PCC Rule 中"剥离"成独立对象，再用引用键关联，是相比 4G 的一个重要演进。4G 的 PCC Rule 把 QCI/ARP/MBR/GBR/Gate/ChargingKey 全塞进一条规则；5G 拆分后，运营商在更新"限速参数"时只需重传 `qosDecs` 数组，无需重传整套规则，显著降低了 N7 信令开销——这对高频策略变更的 5G 切片/边缘场景尤为关键。

## 五、核心机制：PCC Rule 到 QoS Flow 的绑定算法

PCC 规则下发的最终落点是创建/修改 **QoS Flow**。SMF 收到 SmPolicyDecision 后，并不是简单地为每条 PCC Rule 新建一个 QoS Flow，而是执行 TS 23.501 §5.7.1 定义的 **QoS Flow 绑定（QoS Flow Binding）** 算法。这是整个策略执行机制中最精妙、也最容易被误解的一环。

### 绑定参数

SMF 把以下 PCC Rule 派生参数作为"绑定指纹"，判断一条已有 QoS Flow 是否可复用：

| 绑定参数 | 来源 | 作用 |
|---------|------|------|
| 5QI | QosData | QoS 等级，决定是否同流 |
| ARP | QosData | 分配保留优先级（抢占/被抢占） |
| Priority Level | QosData | 调度优先级（若 5QI 非标准化） |
| QNC | QosData | QoS 通知控制标志 |
| Averaging Window | QosData | GBR 平均窗口 |
| Maximum Data Burst Volume | QosData | 最大数据突发量 |

### 绑定决策流程

```mermaid
flowchart TD
    A[SMF收到新PCC Rule] --> B{是否为默认QoS规则<br/>PCF指定绑定默认流?}
    B -->|是| C[绑定到默认QoS Flow<br/>关联DNN默认路由]
    B -->|否| D{是否存在QoS Flow<br/>其QoS参数与绑定指纹完全一致?}
    D -->|是| E[复用该QoS Flow<br/>绑定PCC Rule到已有流<br/>不新建N4/N2资源]
    D -->|否| F{5QI是否为GBR类型?}
    F -->|是 GBR 5QI| G[新建GBR QoS Flow<br/>携带GBR/MBR<br/>触发PDU会话修改/资源预留]
    F -->|否 Non-GBR 5QI| H[新建Non-GBR QoS Flow<br/>受Session-AMBR约束<br/>无独立带宽保证]
    G --> I[执行QoS Flow建立:<br/>N4 PFCP安装QER/PDR<br/>N2 QoS Flow Setup<br/>N1 QoS Rule下发UE]
    H --> I
    E --> J[仅更新PDR/SDF过滤器绑定<br/>无需新建N2资源]
    C --> J

    style A fill:#e3f2fd
    style G fill:#fff9c4
    style H fill:#f1f8e9
    style I fill:#d4edda
```

**算法要点解读**：

1. **复用优先**：SMF 优先判断能否把新 PCC Rule 绑定到一条 QoS 参数完全相同的已有 QoS Flow。若可复用，则只需在 UPF 更新 PDR（包检测规则）的 SDF 过滤器绑定，**不触发空口 N2 信令**，这对减少信令风暴意义重大。

2. **GBR 与 Non-GBR 分流**：若绑定指纹无匹配流，则按 5QI 类型新建。GBR 类型（如 5QI=1 语音、5QI=2/3/4 会话类、5QI=82~85 URLLC）会建立带独立带宽保证的 GBR QoS Flow，触发空口资源预留（gNB 准入控制）；Non-GBR 流则共享 Session-AMBR，无独立保证。

3. **默认 QoS Flow 特殊处理**：每个 PDU 会话有且仅有一个"默认 QoS Flow"，承载默认路由与默认计费策略，生命周期与会话相同，不可单独删除（除非删会话）。PCF 可显式指定某条 PCC Rule 绑定到默认流。

这一绑定算法解释了一个常见的现网困惑：**为什么 PCF 下发了 10 条 PCC 规则，gNB 上却只看到 3 个 QoS Flow？** 因为参数相同的规则被复用了。

## 六、动态 PCC 规则下发与策略控制请求触发条件

SM Policy Association 建立后并非静态。PCF 与 SMF 通过两类交互维持策略的动态性：

- **SMF 报告式**：SMF 在 `policyCtrlReqTriggers`（策略控制请求触发条件，PCRT）命中时，调用 `POST /sm-policies/{id}/update` 主动上报，PCF 据此重新决策。
- **PCF 推送式**：PCF 在签约变更、AF 新需求、计费配额变化等场景，通过事先注册的 `notifUri` 回调 `POST {notifUri}/update`，主动 install/remove PCC 规则（对应 TS 29.513 的 `PolicyUpdateNotification` 操作）。

下表列出常见的 **Policy Control Request Trigger（PCRT）**：

| PCRT | 触发条件 | PCF 典型响应 |
|------|---------|-------------|
| `PLMN_CHANGE` | UE 漫游到新 PLMN | 调整漫游计费/路由策略 |
| `ACCESS_TYPE_CHANGE` | 3GPP↔Non-3GPP 切换 | 变更 QoS 参数与门控 |
| `PDU_SESSION_TYPE` | PDU 会话类型变化 | 重算计费策略 |
| `QOS_FLOW_ALLOCATION_FAILURE` | GBR 流准入失败 | 降级 QoS 或通知 AF |
| `UE_IP_CHANGE` | UE IP 地址变更 | 更新门控/监控绑定 |
| `USAGE_REPORT` | 使用量达到阈值 | 续费配额或限速 |
| `RAT_CHANGE` | 接入技术变化（NR↔LTE） | 调整 5QI 映射 |
| `REFLECTIVE_QOS` | 反射 QoS 触发 | 决定是否下发 RQI |
| `SAT_BACKHAUL` | 卫星回传链路变化 | 特殊时延容错策略 |

## 七、实战连接：抓包识别与故障排查

### 抓包如何识别这个流程

N7 接口是 HTTP/2 over TLS 的 SBI，在抓包工具（Wireshark/`tshark`）中按以下特征过滤：

1. **协议过滤**：`http2` 且 `http2.headers.authority` 含 PCF 域名/IP。
2. **URI 过滤**：请求行含 `/npcf-smpolicycontrol/v1/sm-policies`。
3. **关联 SM Policy**：用 `pduSessionId` + `supi` 关联同一会话的 Establish/Update/Delete。
4. **JSON 解析**：SmPolicyDecision 是 JSON 请求体，Wireshark 可展开 `pccRules`、`qosDecs`、`sessRules` 数组。
5. **端到端关联**：N7 下发后，紧接着应在 N4（PFCP）看到 `PFCP Session Establishment Request` 含对应 QFI 的 QER，在 N2 看到 `PDU Session Resource Setup Request`。

### 常见故障点

| 故障现象 | 可能原因 | 排查思路 |
|---------|---------|---------|
| PCF 返回 4xx，PDU 会话建立失败 | `subsDefQos` 取不到/UDR 签约缺失 | 查 SMF→UDR 鉴权取数、查 UDM/UDR 签约 QoS |
| PCC 规则下发但 QoS Flow 不生效 | 绑定算法选了复用旧流，SDF 过滤器未更新 | 核对 `flowInfos` 5 元组、UPF PDR 安装状态 |
| GBR 业务卡顿 | gNB 准入失败但 SMF 未收到 `QOS_FLOW_ALLOCATION_FAILURE` | 确认 PCRT 是否下发、QNC 是否置位 |
| 计费错配 | `refChgData` 引用的 `ratingGroup` 错误 | 对比 CHF 话单与 PCC 规则计费键 |
| 策略未更新 | `notifUri` 回调失败（SMF 集群漂移） | 检查回调 URI 与 `altNotifIpv4Addrs` 冗余 |
## 八、与 4G PCRF 的对比

| 维度 | 4G PCRF（Gx） | 5G PCF（N7） |
|------|--------------|-------------|
| 接口协议 | Diameter（TCP/SCTP） | HTTP/2 RESTful SBI |
| 策略关联 | IP-CAN Session | SM Policy Association |
| 规则载体 | 单条 PCC Rule 内含全部参数 | 拆分为 qosDecs/chgDecs 等独立数组，引用关联 |
| QoS 单元 | EPS Bearer | QoS Flow（绑定算法更精细） |
| 计费联动 | 通过 Gy/Gx | 通过 CHF（Nchg）/N7 引用 chgDecs |
| 切片感知 | 无（基于 APN） | 原生 S-NSSAI 感知 |
| 动态推送 | Gx RAR（Re-Auth-Request） | PolicyUpdateNotification 回调 |

## 九、常见问题

**Q1: SmPolicyDecision 里的 `sessRules`、`pccRules`、`qosDecs` 三者是什么关系？**
A: `sessRules`（会话规则）定义会话级默认策略（默认 QoS Flow、会话 AMBR）；`pccRules`（PCC 规则）定义具体业务流策略；两者都不直接内含 QoS 参数，而是通过 `refQosData` 引用 `qosDecs`（QoS 数据数组）中的具体 5QI/ARP/GBR/MBR。这种"规则壳 + 参数对象"的引用解耦，是 5G PCC 相比 4G 的核心演进。

**Q2: 一条 PCC Rule 是否一定对应一个新的 QoS Flow？**
A: 不一定。SMF 会按 QoS Flow 绑定算法（TS 23.501 §5.7.1）判断：若已有 QoS Flow 的 5QI/ARP/Priority/QNC/Averaging Window/MDBV 与新规则派生参数完全一致，则复用该流，仅在 UPF 更新 PDR 绑定，不新建 N2 资源。这就是为什么 PCF 下发多条规则，空口 QoS Flow 数量可能远少于规则数。

**Q3: PCF 如何在不等 SMF 请求的情况下主动变更策略？**
A: SMF 在建立 SM Policy Association 时把 `notifUri` 注册给 PCF。当 AF 通过 N5/N30 发起新业务请求、或签约变更、或计费配额耗尽时，PCF 调用 `PolicyUpdateNotification`（`POST {notifUri}/update`）主动 install/modify/remove PCC 规则，SMF 再执行绑定与 PDU 会话修改。

**Q4: 抓包时如何确认策略真正下发到了用户面？**
A: 在 N7 看到 SmPolicyDecision 后，必须在 N4（PFCP）看到对应的 QER（QoS Enforcement Rule，含 GBR/MBR/限速）和 PDR（含 SDF 过滤器与 QFI）安装，并在 N2 看到 QoS Flow 资源建立。仅 N7 成功而 N4 缺失，属于"策略存在于控制面但未落到用户面"的典型故障——3glteinfo 将其概括为"A policy update that never reaches the UPF is not real enforcement, only paperwork."

**Q5: GBR QoS Flow 与 Non-GBR QoS Flow 在策略执行上有何本质区别？**
A: GBR 流（如 5QI=1/2/3/4/82~85）携带独立的 GBR/MBR，会触发 gNB 准入控制与空口资源预留，提供带宽保证；Non-GBR 流没有独立保证，多个 Non-GBR 流共享 Session-AMBR。PCF 通过 PCC Rule 引用的 QosData 中 5QI 是否为 GBR 类型，决定 SMF 走哪条绑定分支。

## 参考来源

1. [3GPP TS 29.513 — Policy and Charging Control signalling flows; Stage 3](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3354) — Npcf_SMPolicyControl 服务定义、SmPolicyDecision、PolicyUpdateNotification
2. [3GPP TS 23.503 — Policy and Charging Control System; Stage 2](https://www.etsi.org/deliver/etsi_ts/129500_129599/129513/15.03.00_60/ts_129513v150300p.pdf)（ETSI 镜像）— PCC 架构、PCC Rule、Policy Decision 总体定义
3. [3GLTEInfo — 5G PCC Policy Enforcement Call Flow](https://www.3glteinfo.com/call-flows/5g/pcc-policy-enforcement/) — 端到端策略执行流程、节点角色、故障排查模式
4. [telecomHall — 5G QoS Flow Binding Process](https://www.telecomhall.net/t/5g-qos-flow-binding-process/27274) — PCC Rule 到 QoS Flow 绑定参数与算法详解
5. [free5GC — Mapping PCC Rules into Session Rules](https://free5gc.org/blog/20241113/20241113/) — 开源实现视角下 PCC Rule 到 Session Rule 映射机制

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

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)