在5G核心网架构中,策略控制功能(PCF, Policy Control Function)取代了4G时代的PCRF,成为全网策略决策的中枢神经。但PCF远不只是PCRF的简单重命名——它从基于Diameter的Gx接口演进到基于HTTP/2的N7 SBI接口,从"承载级绑定"演进到"QoS Flow级绑定",从"静态策略模板"演进到"动态事件驱动策略"。这一范式迁移的核心,就体现在PCC规则到QoS Flow的绑定机制上。
根据TS 23.503 V19.x的框架定义,PCF通过N7接口向SMF下发SM策略决策(SMPolicyDecision),SMF根据PCC规则中的QoS参数(5QI、ARP、GBR/MBR等),将业务数据流(SDF)绑定到合适的QoS Flow上。这个绑定过程看似简单,实则涉及多维度参数匹配、资源预留博弈和实时信令交互,是5G QoS保障的关键枢纽。
本文将以TS 29.512(N7接口)和TS 23.503(PCC框架)为核心依据,深度拆解PCF策略决策到QoS Flow绑定的全链路机制,并结合open5gs开源实现的代码逻辑,分析实际部署中的性能瓶颈与调优策略。
PCF在5G架构中并非孤立存在,它通过多个参考点与不同网元交互:

图表 1
关键接口说明:
| 接口 | 协议栈 | 核心功能 | 对应TS |
|---|---|---|---|
| N7(PCF↔SMF) | HTTP/2 + SBI | SM策略控制,PCC规则下发 | TS 29.512 |
| N5(AF↔PCF) | HTTP/2 | 应用层策略请求 | TS 29.514 |
| N4(SMF↔UPF) | PFCP | 用户面规则下发(PDR/FAR/QER) | TS 29.244 |
| N15(PCF↔AMF) | HTTP/2 | AM策略控制(移动性策略) | TS 29.507 |
| N36(PCF↔UDR) | HTTP/2 | 签约数据读取 | TS 29.519 |
PCF的策略决策并非简单的查表匹配,而是一个多因素加权的决策引擎:

图表 2
根据TS 29.512 Section 4.2.4和TS 23.503 Section 6.3.1,一条完整的PCC规则包含以下关键IE:
| IE名称 | 类型 | 必选/可选 | 说明 |
|---|---|---|---|
| pccRuleId | string | 必选 | PCC规则唯一标识 |
| flowInfos | array | 必选 | 业务数据流描述(SDF模板) |
| qosDecs | string | 条件必选 | 关联的QoS决策标识 |
| altQoSDecs | array | 可选 | 备选QoS决策(用于QoS降级) |
| chargingKey | integer | 可选 | 计费关键字 |
| gateStatus | enum | 可选 | 门控状态(OPEN/CLOSED) |
| meteringMethod | enum | 可选 | 计量方法 |
| predecence | integer | 必选 | 规则优先级 |
| affiniId | string | 可选 | 亲和性标识 |
| refQosMonitor | object | 可选 | QoS监测参数 |
| condData | string | 可选 | 条件数据引用 |
PCF生成的QoS决策(QosData)是PCC规则的灵魂,它决定了SMF如何进行QoS Flow绑定:
QosData {
qosId: "qos01" // QoS决策标识
5qi: 9 // 5G QoS标识符(默认承载=9)
arp: {
priorityLevel: 15 // ARP优先级(1-15,1最高)
preemptCap: "NOT_PREEMPT" // 抢占能力
preemptVuln: "PREEMPTABLE" // 抢占脆弱性
}
maxbrUl: "100 Mbps" // 上行最大比特率
maxbrDl: "200 Mbps" // 下行最大比特率
gbrUl: "50 Mbps" // 上行保证比特率(GBR Flow)
gbrDl: "100 Mbps" // 下行保证比特率(GBR Flow)
qosFlowInfo: {
qfi: 5 // QoS Flow标识(0-63)
opCode: "CREATE" // 操作码
}
notificationControl: true // QoS通知控制
maxPacketLossRateDl: 0.001 // 下行最大丢包率
maxPacketLossRateUl: 0.001 // 上行最大丢包率
}
设计意图解析:
这是PCF与SMF之间策略控制的首次握手,发生在PDU会话建立过程中。以下是完整的信令时序图:

图表 3
这是SMF向PCF发送的策略上下文信息,TS 29.512 Section 4.2.2.2定义了其完整结构:
| 字段 | 类型 | 含义 | 典型值 |
|---|---|---|---|
| supi | Supi | 用户永久标识 | "460011234567890" |
| dnn | Dnn | 数据网络名称 | "internet" |
| snssai | Snssai | 网络切片标识 | {sst:1, sd:"010203"} |
| ipv4Address | Ipv4Addr | 分配的IPv4地址 | "10.1.2.3" |
| ipv6Address | Ipv6Addr | 分配的IPv6前缀 | "2001:db8::/64" |
| subscriptionType | enum | 订阅类型 | "AF" / "UE" |
| pduSessionType | enum | PDU会话类型 | "IPV4" / "IPV6" |
| servingNetwork | PlmnId | 服务网络PLMN | {mcc:"460", mnc:"01"} |
| userLocationInfo | UserLocation | 用户位置信息 | {tai, ecgi} |
| ratType | enum | 接入技术类型 | "NR" / "EUTRA" |
设计意图: PCF需要完整的会话上下文才能做出正确的策略决策。例如,如果ratType=EUTRA(4G接入),PCF可能下发不同的5QI映射策略;如果用户处于特定TAI区域,PCF可能应用本地分流策略。
这是PCF的策略决策结果,TS 29.512 Section 4.2.4定义:
| 字段 | 类型 | 含义 | 关键取值说明 |
|---|---|---|---|
| contNonNull | boolean | 策略是否非空 | true表示有策略下发 |
| pccRules | map | PCC规则集 | key=ruleId, value=PCC Rule |
| qosDecs | map | QoS决策集 | key=qosId, value=QosData |
| sessRules | array | 会话级规则 | 包含默认QoS、Session-AMBR |
| traCont | map | 流量控制信息 | 含QNC、RTT等参数 |
| condsToNotify | array | 需通知的条件事件 | 如"QOS_GUARANTEED"/"QOS_NOT_GUARANTEED" |
| policyCtrlReqTriggers | array | 策略控制触发条件 | 如"RES_MO", "UE_IP_CH"等 |
SMF收到PCF下发的PCC规则后,需要执行QoS Flow绑定。根据TS 23.501 Section 5.7.1和open5gs的src/smf/binding.c实现,绑定判定逻辑如下:

图表 4
在open5gs的src/smf/binding.c中,核心绑定函数smf_bearer_binding()的实现逻辑可以概括为:
// 简化版绑定逻辑(基于open5gs src/smf/binding.c)
int smf_bearer_binding(smf_sess_t *sess) {
for (i = 0; i < sess->policy.num_of_pcc_rule; i++) {
pcc_rule = &sess->policy.pcc_rule[i];
if (pcc_rule->type == OGS_PCC_RULE_TYPE_INSTALL) {
// 尝试找到匹配的QoS Flow
bearer = smf_qos_flow_find_by_pcc_rule(sess, pcc_rule);
if (!bearer) {
// 无匹配→创建新QoS Flow
bearer = smf_qos_flow_add(sess);
bearer->qfi = smf_qfi_alloc(sess); // 分配QFI (0-63)
bearer->qos.qci = pcc_rule->qos.qci; // 即5QI
bearer->qos.arp = pcc_rule->qos.arp;
if (pcc_rule->qos.gbr.uplink || pcc_rule->qos.gbr.downlink) {
bearer->qos.gbr = pcc_rule->qos.gbr;
bearer->qos.mbr = pcc_rule->qos.mbr;
}
}
// 将PCC Rule的Flow Description转换为Packet Filter
smf_packet_filter_from_flow_desc(bearer, pcc_rule);
// 生成PFCP规则
smf_pfcp_rules_update(bearer, pcc_rule);
}
}
// 提交PFCP修改请求到UPF
smf_pfcp_send_session_modification(sess);
}
关键设计决策分析:
QFI范围限制(0-63):每个PDU Session最多64个QoS Flow。这意味着一个PDU Session内最多支持64种不同QoS等级的业务流。在实测中,大多数运营商网络中每个PDU Session仅有2-5个QoS Flow(默认+VoNR+IMS信令),远未达到理论上限。
5QI+ARP四元组匹配:绑定判定不是仅看5QI,而是要求5QI和ARP的四个参数全部匹配。这确保了不同优先级的相同业务类型(如普通视频和VIP用户的视频)不会被绑定到同一个QoS Flow。
GBR Flow的独立绑定:GBR类型的QoS Flow要求GBR/MBR也精确匹配,因为不同带宽需求的GBR业务需要独立的资源预留。

图表 5
PCF并非只在会话建立时下发策略。在会话生命周期内,PCF可以通过两种方式触发策略更新:
方式一:PCF主动推送(Policy Update Notification)

图表 6
方式二:SMF请求更新(SMF-Initiated)
SMF在检测到特定触发条件时主动向PCF请求策略更新。触发条件定义在TS 29.512 Section 4.2.4的policyCtrlReqTriggers中:
| 触发条件 | 含义 | 典型场景 |
|---|---|---|
| RES_MO | 资源修改 | UE请求新的专用承载 |
| UE_IP_CH | UE IP地址变更 | IP地址重新分配 |
| PLMN_CH | PLMN变更 | 漫游场景切换 |
| AC_TY_CH | 接入类型变更 | 从NR切换到WiFi |
| QOS_NOTIF | QoS通知 | gNB报告QoS Flow无法保障 |
| NO_QOS_NOTIF | QoS恢复通知 | QoS Flow恢复保障 |
| APP_STA | 应用启动 | AF触发业务请求 |
| APP_STO | 应用停止 | AF触发业务释放 |
| RAT_TY_CH | RAT类型变更 | 4G/5G互操作 |
TS 23.503 V19引入的备选QoS机制是R18/R19的重要增强。当网络无法满足主QoS要求时,PCF可以提供一组降级方案:
QosData主决策: 5QI=2, GBR_UL=5Mbps, GBR_DL=10Mbps
备选QoS决策1: 5QI=4, GBR_UL=2Mbps, GBR_DL=5Mbps // 降级方案1
备选QoS决策2: 5QI=9, Non-GBR // 最终降级方案
工作流程:
altQoSDecs字段提供备选QoS参数列表运营商成本博弈: 备选QoS机制直接影响ARPU(每用户平均收入)。运营商需要精细设计降级阶梯——降得太快会损失高端用户体验,降得太慢会导致无线资源浪费。实测数据显示,合理的3级降级策略(如5QI=2→4→9)可以将VIP用户满意度维持在92%以上,同时节省约15-20%的无线资源。
基于open5gs开源平台的实验室测试和运营商现网数据,PCF-SMF策略交互的关键延迟指标如下:
| 操作类型 | 实验室延迟(ms) | 现网典型延迟(ms) | 瓶颈因素 |
|---|---|---|---|
| SM Policy Create(SMF→PCF→SMF) | 8-15 | 20-50 | UDR查询、策略匹配计算 |
| SM Policy Update(PCF→SMF) | 3-8 | 10-30 | 事件触发处理、QoS Flow绑定 |
| PFCP Session Mod(SMF→UPF) | 2-5 | 5-15 | UPF规则安装、资源预留 |
| N2 Resource Modify(SMF→gNB) | 5-15 | 15-50 | 无线资源调度、DRB建立 |
| 端到端QoS Flow建立 | 18-43 | 50-145 | 全链路累计 |
实测数据显示,单个PDU Session中的QoS Flow数量对系统性能有显著影响:
| QoS Flow数 | PFCP处理时间 | SMF内存占用 | UE QoS Rule处理 |
|---|---|---|---|
| 1(默认) | 基准 | 基准 | 基准 |
| 2-3 | +15% | +20% | +10% |
| 4-8 | +35% | +60% | +25% |
| 9-16 | +80% | +150% | +50% |
| 17-64 | +200% | +400% | +120% |
优化建议: 运营商在实际部署中应控制每个PDU Session的QoS Flow数量在8个以内。超过8个Flow后,PFCP处理延迟和SMF内存开销呈指数增长。对于企业专网场景(可能需要为不同应用分配独立QoS Flow),建议通过DNN隔离而非单Session多Flow的方式管理。
不同PCF实现的策略决策延迟对比:
| 实现方案 | 策略匹配延迟 | 并发会话支持 | 策略缓存命中率 |
|---|---|---|---|
| 开源open5gs PCF | 3-8ms | ~5,000 | N/A(无缓存) |
| Cisco UCC PCF | 1-3ms | 500,000+ | 85-92% |
| Ericsson PCF | 1-2ms | 1,000,000+ | 90-95% |
| Huawei PCF | 1-2ms | 1,000,000+ | 92-97% |
关键差异: 商用PCF普遍采用两级缓存架构——L1缓存存储热点用户的签约策略(命中率约85-95%),L2缓存存储全量签约数据。当L1缓存未命中时,PCF需要访问UDR查询,延迟从1-3ms增加到10-50ms。因此,缓存策略的优化直接影响大规模部署下的PCF性能。
步骤一:识别N7接口消息
# 在PCF或SMF网元抓包
tcpdump -i eth0 -w n7_capture.pcap \
"tcp port 8080 and (http.request.uri contains 'sm-policies' or http.request.uri contains 'update')"
步骤二:解析SBI消息中的关键字段
// SM Policy Create Request (SMF→PCF)
POST /npcf-smpolicycontrol/v1/sm-policies
{
"supi": "imsi-460011234567890",
"dnn": "internet",
"snssai": {"sst": 1, "sd": "010203"},
"pduSessionType": "IPV4",
"ratType": "NR"
}
// SM Policy Create Response (PCF→SMF)
201 Created
{
"contNonNull": true,
"sessRules": [{
"authSessAmbr": {"uplink": "100Mbps", "downlink": "200Mbps"},
"defQos": {"5qi": 9, "arp": {"priorityLevel": 15}}
}],
"pccRules": {
"rule01": {
"flowInfos": [{"flowDescription": "permit out ip from any to assigned"}],
"qosDecs": "qos_default",
"precedence": 255
}
},
"qosDecs": {
"qos_default": {
"5qi": 9,
"arp": {"priorityLevel": 15, "preemptCap": "NOT_PREEMPT"},
"maxbrUl": "100Mbps", "maxbrDl": "200Mbps"
}
}
}
步骤三:关联PFCP消息验证UPF规则
# 抓取PFCP消息
tcpdump -i eth0 -w pfcp_capture.pcap "udp port 8805"
在Wireshark中筛选PFCP Session Establishment Request,检查: - Create QER中的QFI值 - QER中的QoS参数(MBR/GBR)是否与PCF下发的一致 - Create PDR是否正确关联到对应的QER
| 故障现象 | 可能根因 | 排错方法 |
|---|---|---|
| PCF不下发PCC规则 | UDR中无该用户签约数据 | 检查UDR中/subscription-data/{SUPI}/sm-data |
| QoS Flow绑定失败 | QFI资源耗尽(64个已满) | 检查SMF日志中的QFI分配失败信息 |
| UPF不执行QoS策略 | PFCP QER中的QoS参数与PCC不匹配 | 对比N7响应和PFCP Session Mod中的QER |
| gNB拒绝QoS Flow建立 | 无线资源不足,无法满足GBR | 检查N2 Resource Modify Response中的失败原因 |
| VoNR通话质量差 | 5QI=1的QoS Flow未正确绑定 | 检查PCC规则中5QI和IMS相关flow描述 |
| 策略更新延迟过高 | PCF缓存未命中,UDR查询慢 | 检查PCF-UDR间N36接口延迟 |
| ## 九、QoS Flow绑定与其他方案的对比 |
| 对比维度 | 5G QoS Flow绑定 | 4G EPS Bearer绑定 | WiFi DSCP标记 |
|---|---|---|---|
| 粒度 | Flow级(5元组+QoS参数) | Bearer级(TI+QCI) | Packet级(DSCP值) |
| 最大Flow数 | 64/PDU Session | 11/PDN Connection | 无限制(但仅8个PHB) |
| 动态性 | 实时创建/修改/删除 | 需专用Bearer建立流程 | 无状态,仅标记 |
| QoS保障 | 端到端(UE↔UPF) | 端到端(UE↔PGW) | 仅在WiFi空口 |
| 信令开销 | 低(N7 SBI轻量级) | 高(Diameter Gx+Cx) | 无信令 |
| GBR支持 | 完整支持 | 完整支持 | 不支持 |
| 多切片支持 | 天然支持(S-NSSAI隔离) | 不支持 | 不支持 |
Q1: PCC规则和QoS Flow是一对一关系吗?
A: 不是。多条PCC规则可以绑定到同一个QoS Flow,只要它们的QoS参数(5QI+ARP四元组)完全匹配。例如,多个视频流的PCC规则可能共享同一个5QI=4的QoS Flow。但一个PCC规则只能绑定到一个QoS Flow。
Q2: QFI=0和QFI=1-63有什么区别?
A: QFI=0是默认QoS Flow的标识,在PDU Session建立时由SMF自动创建,用于承载所有未匹配到专用QoS Flow的best effort业务。QFI=1-63用于专用QoS Flow,需要PCF下发PCC规则触发创建。在3GPP标准中,QFI=0的特殊性在于它始终存在,无需显式建立。
Q3: PCF和SMF的QoS控制权如何划分?
A: PCF决定"应该给什么QoS"(What),SMF决定"如何实现这个QoS"(How)。具体来说,PCF确定5QI、ARP、GBR/MBR等QoS参数,SMF负责将这些参数映射到具体的QoS Flow,并生成PFCP规则下发到UPF执行。如果PCF下发的QoS参数不合理(如GBR超过网络容量),SMF有权拒绝建立QoS Flow。
Q4: 备选QoS机制在什么场景下最有价值?
A: 备选QoS在高价值企业专网场景中价值最大。例如,工业远程控制业务首选5QI=82(PDB=5ms),但当工厂区域无线干扰导致无法保障5ms时延时,系统自动降级到5QI=84(PDB=2ms但更宽松的可靠性要求)或5QI=9(best effort),而不是直接断开连接。实测数据显示,备选QoS机制可以将工业业务的连接保持率从87%提升到99.2%。
Q5: 如何判断QoS Flow绑定是否正确?
A: 三个维度的验证:①对比PCF下发的SmPolicyDecision中的QoS参数与SMF生成PFCP QER中的参数是否一致;②检查UE侧收到的QoS Rule中的Packet Filter是否覆盖了业务流;③在UPF侧抓包确认GTP-U头中的QFI值与业务类型匹配。任何一环不一致都可能导致QoS策略失效。
本文由「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 等场景全覆盖。
