多 PCF 部署中的真正挑战,并不在于存在多个 PCF 实例本身。问题在于,同一个 UE 在不同业务流程中很容易被路由到不同的 PCF。PDU 会话建立期间,SMF 可能已经与某个 PCF 建立了策略关联。随后,当 IMS 语音业务触发、AF 发起新的策略请求时,负载均衡可能把该请求发送到另一个 PCF。一旦发生这种情况,两个阶段之间的策略上下文就会被割裂,从而可能导致 VoNR QoS 流、PCC 规则和会话策略不一致。
BSF,即绑定支持功能(Binding Support Function),就是专门用于解决这类问题:同一用户跨不同接口发起的请求,需要到达同一个 PCF。BSF 不生成 PCC 规则,也不会替代 PCF 做策略决策。它的核心职责是维护 UE 会话与关联 PCF 之间的绑定关系,使后续请求到来时,业务消费者能够找到此前已经参与该用户策略控制的 PCF。
为什么多 PCF 网络可能选错 PCF
要理解 BSF 的价值,可以先回顾 4G 中已经存在的类似问题。在 EPC 架构中,PGW 通过 Gx 接口与 PCRF 通信,而 IMS 域中的 P-CSCF 通过 Rx 接口发送策略授权请求。当部署多个 PCRF 时,Gx 和 Rx 两条信令路径最终必须到达同一个 PCRF,否则后续 IMS 业务请求就无法继承会话早期已经建立的策略上下文。
在 4G 网络中,常见做法是使用 DRA 进行 Diameter 路由和会话绑定。以一个典型场景为例:PGW 为 IMS APN 建立 PDN 连接时,Gx 请求经 DRA1 被路由到 PCRF1,DRA1 记录 IMSI、UE IP 地址与 PCRF1 之间的关系。如果后续来自 P-CSCF 的 Rx 消息因为负载均衡被发送到 DRA2,而 DRA2 又把请求转发给 PCRF2,那么 PCRF2 并不知道此前在 PGW 一侧已经建立的会话上下文。
其影响远不只是“选错服务器”这么简单。PCRF2 不具备现有 PCC 规则状态,因此通过 Rx 收到的新媒体策略请求无法与此前通过 Gx 建立的策略正确关联。在 4G 部署中,可以通过多个 DRA 之间实时同步绑定信息来解决这一问题,但这类实现通常具有厂商私有性,会显著增加多厂商部署和长期运维的复杂度。
在 5GC 中,尽管网络功能和接口发生了变化,对策略一致性的要求仍然相同。SMF 通过 N7 与 PCF 通信,AF 则通过 N5 请求策略授权。在完整的 VoNR 策略流程中,AF 首先提供应用流和 QoS 要求,PCF 生成对应的 PCC 规则,随后由 SMF 和 UPF 执行这些规则。如果同一 UE 的不同请求到达不同 PCF,策略连续性仍然可能被破坏。
BSF 实际上把过去依赖私有同步机制的绑定能力进行了标准化。它维护当前 UE 会话与负责该会话的 PCF 之间的关系,帮助确保后续策略请求能够重新路由到此前已经参与该会话的 PCF 实例。
BSF 绑定哪些信息?
从实现角度看,BSF 可以视为一张动态维护的“UE 到策略归属”表。某个 PCF 参与 UE 的 PDU 会话策略控制后,会向 BSF 注册所需的绑定信息。后续其他网络功能可以利用 UE 标识和会话特征查询 BSF,从而获得对应 PCF 的寻址信息。
一条典型绑定记录可能包括 UE IP 地址、SUPI、DNN、S-NSSAI,以及关联 PCF 的地址。在需要与传统 Diameter 接口互通的部署中,记录还可能包括 PCF 的 Diameter 主机名或 FQDN。
这些字段并不是为了信息完整而简单收集。每个字段在筛选和识别正确绑定时都有明确作用:
-
UE IP: 基于当前用户面地址直接定位绑定,是最常用的查询参数之一。
-
SUPI: 从用户身份层面标识订阅用户,有助于确保绑定属于正确的 UE。
-
DNN: 区分同一 UE 使用的不同数据网络,例如 IMS 与普通互联网业务。
-
S-NSSAI: 在网络切片化的 5G 部署中,进一步标识该会话所属的网络切片。
-
PCF 地址: 提供业务消费者访问所选 PCF 所需的实际寻址信息。
-
Diameter 主机名/FQDN: 在 SBI 与 Diameter 共存的部署中,为传统 Diameter 路由提供映射参考。
因此,BSF 绑定不能被简化为 UE 地址与 PCF 地址之间简单的一对一映射。单个 UE 可以拥有多个 PDU 会话,也可能访问不同 DNN 或不同网络切片。如果查询条件过于宽泛,返回的 PCF 可能与当前业务上下文不匹配。
在实际部署中,绑定粒度应与策略控制粒度保持一致。这一点对 IMS 业务尤其重要,因为策略连续性非常关键。如果 UE 存在多个切片或多个数据网络上下文,DNN 和 S-NSSAI 不应从绑定条件中省略。
Nbsf_Management 应该如何使用?
BSF 通过 SBI 提供 Nbsf_Management 服务。该服务并不是由大量彼此无关的 API 堆叠而成,而是提供覆盖绑定记录完整生命周期的四项核心操作:注册、发现、更新和注销。在实际部署中,这四项操作可以直接对应 PCF 绑定的创建、使用、维护和删除。
注册:先创建绑定
PCF 被选中并开始参与 UE 的策略控制后,需要向 BSF 注册绑定。一个典型请求为:
POST .../pcfBindings
请求体可以包含 UE IP 地址、SUPI、DNN、S-NSSAI、PCF 地址以及对应 FQDN 等关键字段。BSF 成功创建绑定记录后,会返回:
201 Created
时序是这一阶段最常见的实现陷阱之一。必须在后续任何业务侧查询发起之前完成绑定注册。否则,当 AF 侧请求或兼容 Diameter 的请求到达网络时,BSF 可能还没有对应的 PCF 绑定,从而导致查询失败。
发现:从会话上下文中找回既有 PCF
Discovery 操作最能体现 BSF 的实际价值。业务消费者使用当前可获得的 UE 信息发起查询:
GET .../pcfBindings?query_parameters
查询参数可以包括 UE IP 地址、SUPI 或 GPSI、DNN、S-NSSAI 以及其他相关标识。如果找到匹配的绑定,BSF 返回:
200 OK
响应中包含对应 PCF 地址,并在需要时包含 Diameter 主机名或 FQDN。在标准化架构中,业务消费者可包括 NEF、AF、NWDAF 等功能。在仍需支持传统 Rx 路由的部署中,返回的绑定信息也可用于为后续信令选择正确的 PCF。
更新与注销:维护绑定生命周期
如果绑定信息发生变化,可使用 PATCH 更新现有记录:
PATCH .../pcfBindings/{bindingId}
更新成功后返回 200 OK。当会话释放、PCF 不再为该 UE 提供服务,或绑定失效时,应使用以下方式删除记录:
DELETE .../pcfBindings/{bindingId}
删除成功通常返回 204 No Content。在实际部署中,注销步骤不应被忽略。如果过期绑定长期保留在 BSF 中,同一用户后续建立新会话时可能误匹配到旧 PCF。这类问题往往比单纯缺少绑定更难排查。
如何排查 N7 与 Rx 绑定问题
从完整信令路径来看,BSF 工作流可以分为三个阶段:先注册绑定,再查询绑定,最后把后续策略信令路由回原始 PCF。明确这一顺序后,排查 VoNR 策略问题会比没有方向地大量抓取信令高效得多。
阶段一:建立 PDU 会话并注册 PCF
BSF 实例上线后,首先向 NRF 注册自身能力和寻址信息。随后 UE 为 IMS DNN 建立 PDU 会话,SMF 向 PCF 请求策略控制。PCF 被选中后,会调用 Nbsf_Management_Register,把 UE 到 PCF 的绑定存入 BSF。
此时,BSF 中可能包含类似如下的绑定记录:
UE IP1 + DNN1 + S-NSSAI1 + SUPIxx → PCF1 UE IP2 + DNN2 + S-NSSAI2 + SUPIyy → PCF2
阶段二:VoNR 呼叫触发策略查询
当 UE 发起 VoNR 呼叫时,IMS 域会触发新的策略授权请求。在标准 5GC 架构中,AF 与 PCF 通过 N5 接口交换策略信息。在一些仍继续使用传统 IMS Diameter 信令的部署中,P-CSCF 可能仍采用 Rx/AAR 流程。
这一阶段的关键问题很直接:策略请求应该发送给哪个 PCF?
请求方不应仅依据常规负载均衡逻辑再选择一个 PCF,而应先利用 UE 地址、DNN、S-NSSAI 等信息查询 BSF。BSF 匹配现有绑定记录,并返回已经负责该 UE 会话的 PCF 实例。
阶段三:把后续信令路由回原始 PCF
确定正确 PCF 后,后续策略请求都应发送到同一 PCF。这样,PDU 会话建立阶段创建的策略上下文,以及 VoNR 媒体阶段产生的新策略请求,就会始终位于同一个策略控制实例上。PCF 因而可以基于完整的会话上下文生成并维护 PCC 规则。
如果 VoNR 呼叫能够发起,但 QoS 策略行为异常、IMS 媒体规则不一致,或者只有部分用户出现间歇性失败,在立即把问题归因于无线网络之前,应先检查 BSF 绑定路径。
实际排查可以分为四步。第一,确认 PDU 会话建立后确实执行了 BSF Register 操作。第二,核对 BSF 中保存的 UE IP 地址、SUPI、DNN、S-NSSAI 是否正确。第三,检查后续 Discovery 请求使用的查询条件能否唯一匹配原始绑定。第四,确认返回的 PCF 地址或 Diameter 标识与最初参与 N7 策略控制的 PCF 完全一致。
还需要考虑部署架构。在某些网络中,BSF 可能与 SMF 共址部署,此时抓包位置和内部调用流程可能与独立 BSF 部署不同。但基本原则不变:网络必须在 UE 会话与负责该会话的 PCF 之间维持稳定绑定。
常见问题
BSF 和 NRF 都负责网络功能选择吗?
不是。两者角色不同。NRF 帮助网络功能发现可用的 NF 实例及其能力,更接近一个服务注册中心;BSF 则保存某个具体 UE 会话与 PCF 之间已经建立的绑定。简单来说,NRF 回答的是“有哪些 PCF 可用?”,而 BSF 回答的是“当前这个 UE 会话已经由哪个 PCF 负责?”
一个 UE 只能有一条 PCF 绑定吗?
不一定。绑定并不是只由 UE 身份决定,还可能取决于 DNN、S-NSSAI 以及具体 PDU 会话上下文。如果同一个 UE 访问不同数据网络或网络切片,相应绑定可能需要分别维护。
BSF 和 SMF 可以部署在同一个网络功能实例中吗?
可以。两者可以共址部署。在这种情况下,对外可见的信令顺序可能与独立 BSF 部署不同,但 UE 到 PCF 的绑定仍然需要被保存并使用。因此排查问题时,应首先确认实际厂商的部署架构。
BSF 查询失败时首先应该检查什么?
先检查三项:绑定记录是否成功创建、查询参数是否与注册时使用的值一致,以及绑定是否已经过期或被过早删除。如果 BSF 能够返回记录,还应确认返回的 PCF 地址、FQDN 或 Diameter 标识是否指向预期的 PCF 实例。