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 通过两条核心服务对外提供策略：

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

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

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 步之间。完整时序如下：

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 如下：

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

四、SmPolicyDecision 数据结构深度拆解

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

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 中最核心的策略单元，下表逐一说明其关键字段：

设计意图剖析：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 是否可复用：

绑定决策流程

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）：

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

抓包如何识别这个流程

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。

常见故障点

九、常见问题

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 — Npcf_SMPolicyControl 服务定义、SmPolicyDecision、PolicyUpdateNotification
2. 3GPP TS 23.503 — Policy and Charging Control System; Stage 2（ETSI 镜像）— PCC 架构、PCC Rule、Policy Decision 总体定义
3. 3GLTEInfo — 5G PCC Policy Enforcement Call Flow — 端到端策略执行流程、节点角色、故障排查模式
4. telecomHall — 5G QoS Flow Binding Process — PCC Rule 到 QoS Flow 绑定参数与算法详解
5. free5GC — Mapping PCC Rules into Session Rules — 开源实现视角下 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 等场景全覆盖。