《5G核心网原理与实践》实践篇 · BSF 网元功能
作者：爱卫生
在第13篇中，我们讨论了IP地址重叠场景下通过ipDomain区分不同用户的解决方案。但如果查询方（DRA/AF）没有携带ipDomain参数，或者网络中出现了异常的绑定信息重复，BSF查询时可能匹配到多条绑定记录。
这是一个必须被正确处理的异常场景。如果BSF返回多条绑定记录，DRA/AF将无法确定应该将策略授权请求路由到哪个PCF。3GPP协议对此有明确规定：当查询匹配到多条绑定记录时，BSF应返回400 Bad Request错误。
本篇聚焦于查询到的会话绑定信息不唯一这一异常场景，验证BSF在该场景下返回400 Bad Request的正确行为。
在正常的网络运营中，同一IP地址不应该出现多条绑定记录（除非使用ipDomain区分）。但在以下异常情况下可能出现：
未携带ipDomain查询：查询方没有携带ipDomain参数，而BSF中同一IP地址属于不同ipDomain存在多条绑定；
绑定信息残留：旧的绑定信息未被正确删除（如PDU会话释放流程异常中断），与新的绑定信息同时存在；
网络配置错误：同一SMF/BSF内错误地创建了重复的绑定记录；
UE多会话场景：同一UE建立了多个PDU会话，且分配了相同的IP地址（这种场景理论上不应出现，但配置错误时可能发生）。
本测试同样采用对比验证法：
正对照：用户A的IP地址查询返回唯一绑定信息（200 OK），策略授权正常完成；
负对照：用户B的IP地址查询返回多条绑定信息（400 Bad Request），BSF拒绝返回模糊结果。
同时，通过在BSF上额外增加两条与用户B使用相同IP地址的绑定信息来构造绑定不唯一的场景。
sequenceDiagram
participant DRA as DRA/SCEF/AAC
participant BSF as SMF/BSF
participant PCF1 as PCF1
participant PCF2 as PCF2
Note over DRA, PCF2: 前置条件设置
Note over DRA, PCF2: 用户A和用户B已建立PDU会话
Note over DRA, PCF2: 额外增加UE_C和UE_D的绑定信息
Note over DRA, PCF2: UE_B和UE_D的IP地址与UE_C重复
Note over DRA, PCF1: 场景1: 查询用户A的绑定 - 唯一匹配
DRA->>BSF: GET /pcfBindings ipv4Addr=172.24.6.2
Note right of DRA: Nbsf_Management_Discovery_Req
BSF-->>BSF: 内部查找: 匹配1条记录
BSF-->>DRA: 200 OK (用户A唯一绑定信息)
Note left of BSF: 返回SUPI A + PCF1绑定
DRA->>PCF1: AAR (Rx接口策略授权请求)
PCF1-->>DRA: AAA (Rx接口策略授权响应)
Note over DRA, PCF2: 场景2: 查询用户B的绑定 - 匹配多条记录
DRA->>BSF: GET /pcfBindings ipv4Addr=172.24.6.2
Note right of DRA: Nbsf_Management_Discovery_Req<br/>同一IP地址
BSF-->>BSF: 内部查找: 匹配多条记录
BSF-->>DRA: 400 Bad Request
Note left of BSF: 绑定信息不唯一<br/>拒绝返回模糊结果
flowchart LR
subgraph 查询唯一绑定
A1["DRA查询用户A的IP"] --> B1["BSF匹配到1条记录"]
B1 --> C1["返回200 OK"]
C1 --> D1["DRA正常路由到PCF"]
end
subgraph 查询不唯一绑定
A2["DRA查询用户B的IP"] --> B2["BSF匹配到多条记录"]
B2 --> C2["返回400 Bad Request"]
C2 --> D2["DRA无法确定PCF"]
end
style B1 fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
style C1 fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
style B2 fill:#ffcdd2,stroke:#c62828,stroke-width:2px
style C2 fill:#ffcdd2,stroke:#c62828,stroke-width:2px
TS 29.551（Nbsf_Management服务）：第5.2.2.2节定义了Nbsf_Management_Discovery操作的异常处理。当查询参数匹配到多条PcfBinding记录时，BSF应返回400 Bad Request错误，错误原因指示绑定信息不唯一。
TS 29.513（PCF策略控制）：第4.2节描述了Rx接口会话绑定的错误处理机制。
TS 23.501（5G系统架构）：第5.8.2.6节描述了BSF在策略控制架构中的角色，强调绑定记录的唯一性要求。
400 Bad Request在BSF查询场景中表示"请求虽然格式正确，但由于绑定信息不唯一，BSF无法返回确定的结果"。这与以下错误码有所区别：
| 响应码 | 含义 | 典型场景 |
|---|---|---|
200 OK |
唯一匹配成功 | 查询到恰好1条绑定记录 |
|---|---|---|
204 No Content |
无匹配记录 | 绑定信息不存在（见第14篇） |
400 Bad Request |
匹配不唯一 | 同一IP地址匹配多条记录 |
400 Bad Request |
请求参数错误 | 缺少必要参数或参数格式错误 |
当出现绑定信息不唯一的情况时，有以下解决思路：
携带ipDomain参数：查询时携带ipDomain参数，缩小查询范围，确保匹配结果唯一（第13篇已验证）；
携带SUPI参数：查询时携带SUPI参数，进一步精确匹配；
携带DNN参数：通过DNN缩小查询范围；
网络运维：检查并清理重复的绑定记录，确保每个（IP+ipDomain）组合只有一条绑定。
flowchart TD
A["BSF返回400 Bad Request"] --> B["绑定信息不唯一"]
B --> C["原因1: 未携带ipDomain"]
B --> D["原因2: 旧绑定未清除"]
B --> E["原因3: 配置错误"]
C --> F["解决方案: 查询时携带ipDomain"]
D --> G["解决方案: 排查PDU会话释放流程"]
E --> H["解决方案: 检查网络配置"]
F --> I["查询返回唯一结果"]
G --> I
H --> I
style B fill:#ffcdd2,stroke:#c62828,stroke-width:2px
style I fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
网络中BSF、DRA或SCEF/AAC、PCF1、PCF2网元系统及操作维护台运行正常；
用户A（IMSI: 4608800000XXXXXA）附着成功，SMF/BSF已创建IMS PDU会话和数据业务PDU会话；
用户B（IMSI: 4608800000XXXXXB）附着成功，SMF/BSF已创建IMS PDU会话和数据业务PDU会话；
DRA或SCEF/AAC上已配置用户IP地址段和BSF ID或地址的对应关系；
IMS AF或SCEF/AAC接入DRA，采用Rx接口访问PCF。
为模拟绑定信息不唯一的场景，在SMF/BSF上额外增加两条绑定信息，使其IP地址与用户B的IP地址重复：
增加UE_C（IMSI: 4608800000XXXXXC）：附着成功，SMF/BSF创建PDU会话，分配IP地址172.24.6.4；
增加UE_D（IMSI: 4608800000XXXXXD）：附着成功，SMF/BSF创建PDU会话，分配IP地址与用户A相同（172.24.6.2），构造绑定不唯一。
在SMF/BSF上进行消息跟踪/抓包操作；
在SMF/BSF上增加两条会话绑定信息，使IP地址与用户A的IP地址重复；
用户A发起语音业务或数据业务，触发策略授权请求操作；
用户B发起语音业务或数据业务，触发策略授权请求操作。
flowchart TD
A["BSF收到查询请求"] --> B["解析查询参数"]
B --> C["在绑定数据库中搜索"]
C --> D{"匹配记录数量"}
D -->|"0条"| E["返回204 No Content"]
D -->|"1条"| F["返回200 OK和绑定信息"]
D -->|"多条"| G["返回400 Bad Request"]
style E fill:#fff9c4,stroke:#f57f17,stroke-width:2px
style F fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
style G fill:#ffcdd2,stroke:#c62828,stroke-width:2px
用户A（IMSI: 4608800000XXXXXA）附着成功，SMF/BSF已创建PDU会话：
[local]SMF07#epg smf user-info identifier-type imsi value 4608800000XXXXXA
mobile-user-information:
subscriber-information:
imsi: 4608800000XXXXXA
msisdn: 86138000XXXXXA
imei: 88723900XXXXXA0
active-pdu-sessions:
active-pdu-session:
pdu-session-id: 5
dnn-in-use: apn1
an-type: 3GPP
ssc-mode: SSC_MODE_1
ue-address-1:
ipv4: 172.24.6.2
ip-address-allocation-method: Shared IP Pool
single-nssai:
slice-service-type: 5
slice-differentiator: 000001
nr-location:
tai:
plmn-id: mnc88.mcc460
tac: 10
ncgi:
plmn-id: mnc88.mcc460
nr-cell-id: 15269888
amf-information:
amf-id: 844fb18e-cf1b-4a44-930b-9bbf0c413b1c
address: 10.10.32.125:8080
n3-interface:
ran-fteid:
teid: 1342177293
address: 174.38.0.32
upf-fteid:
teid: 1415577601
address: 2a01:10:185:255::8
n4-interface:
local-fseid:
seid: 739465664
address: 10.10.32.96
qos-flows:
qos-flow:
qos-flow-id: 5
fiveQi: 5
allocation-retention-priority:
priority-level: 1
pre-emption-capability: Disabled
pre-emption-vulnerability: Disabled
session-ambr:
uplink-kbps: 123457
downlink-kbps: 1235000
用户B（IMSI: 4608800000XXXXXB）附着成功：
[local]SMF07#epg smf user-info identifier-type imsi value 4608800000XXXXXB
mobile-user-information:
subscriber-information:
imsi: 4608800000XXXXXB
msisdn: 86138000XXXXXB
imei: 88723900XXXXXB0
active-pdu-sessions:
active-pdu-session:
pdu-session-id: 5
dnn-in-use: apn1
an-type: 3GPP
ssc-mode: SSC_MODE_1
ue-address-1:
ipv4: 172.24.6.3
single-nssai:
slice-service-type: 5
slice-differentiator: 000001
amf-information:
amf-id: 844fb18e-cf1b-4a44-930b-9bbf0c413b1c
address: 10.10.32.125:8080
session-ambr:
uplink-kbps: 123457
downlink-kbps: 1235000
为构造绑定不唯一场景，增加UE_C（IMSI: 4608800000XXXXXC）：
[local]SMF07#epg smf user-info identifier-type imsi value 4608800000XXXXXC
mobile-user-information:
subscriber-information:
imsi: 4608800000XXXXXC
msisdn: 86138000XXXXXC
imei: 88723900XXXXXC0
active-pdu-sessions:
active-pdu-session:
pdu-session-id: 5
dnn-in-use: apn1
ue-address-1:
ipv4: 172.24.6.4
single-nssai:
slice-service-type: 5
slice-differentiator: 000001
n3-interface:
ran-fteid:
teid: 1342177295
address: 174.38.0.33
session-ambr:
uplink-kbps: 123457
downlink-kbps: 1235000
增加UE_D（IMSI: 4608800000XXXXXD），其IP地址与用户A相同（172.24.6.2）：
[local]SMF07#epg smf user-info identifier-type imsi value 4608800000XXXXXD
mobile-user-information:
subscriber-information:
imsi: 4608800000XXXXXD
msisdn: 86138000XXXXXD
imei: 88723900XXXXXD0
active-pdu-sessions:
active-pdu-session:
pdu-session-id: 6
dnn-in-use: Internet10
ue-address-1:
ipv4: 172.24.6.2
single-nssai:
slice-service-type: 5
slice-differentiator: 000001
amf-information:
amf-id: 844fb18e-cf1b-4a44-930b-9bbf0c413b1c
address: 10.10.32.125:8080
n3-interface:
ran-fteid:
teid: 1610612752
address: 174.38.0.32
upf-fteid:
teid: 1739587585
address: 10.185.255.11
n4-interface:
local-fseid:
seid: 665890640
address: 10.10.32.96
session-ambr:
uplink-kbps: 1500000
downlink-kbps: 2000000
| UE | IMSI | IPv4地址 | DNN | PDU Session ID | AMBR |
|---|---|---|---|---|---|
| UE B | ...XXXXXB | 172.24.6.3 | apn1 | 5 | 123457/1235000 |
|---|---|---|---|---|---|
| UE C | ...XXXXXC | 172.24.6.4 | apn1 | 5 | 123457/1235000 |
| UE D | ...XXXXXD | 172.24.6.2 | Internet10 | 6 | 1500000/2000000
关键发现： UE_A和UE_D使用相同的IPv4地址（172.24.6.2），但属于不同的DNN（apn1 vs Internet10）和不同的SUPI。当DRA使用该IP地址查询BSF时，BSF将匹配到两条绑定记录。
基于用户B（IMSI: ...XXXXXB）IP地址的会话绑定信息查询请求，SMF/BSF针对用户B的IP地址（172.24.6.3）查询到唯一的会话绑定信息，返回200 OK。
由于用户B的IP地址（172.24.6.3）只有一条绑定记录，BSF能够确定性地返回结果。
基于用户A（IMSI: ...XXXXXA）IP地址的会话绑定信息查询请求，由于用户A和UE_D使用相同的IP地址（172.24.6.2），BSF匹配到两条绑定记录。BSF返回400 Bad Request，拒绝返回模糊的查询结果。
BSF内部处理逻辑：
BSF收到查询请求: GET /pcfBindings?ipv4Addr=172.24.6.2
BSF绑定数据库搜索:
记录1: SUPI=...XXXXXA, DNN=apn1, IPv4=172.24.6.2 -> PCF1
记录2: SUPI=...XXXXXD, DNN=Internet10, IPv4=172.24.6.2 -> PCF2
匹配结果: 2条记录（不唯一）
BSF返回: 400 Bad Request
原因: 查询到的会话绑定信息不唯一
结合第14篇和本篇，BSF查询有三种可能的返回结果：
| 场景 | 匹配记录数 | BSF响应 | 说明 |
|---|---|---|---|
| 唯一匹配 | 1 | 200 OK + 绑定信息 | 正常场景 |
| 无匹配 | 0 | 204 No Content | 绑定不存在（第14篇） |
| 多条匹配 | >=2 | 400 Bad Request | 绑定不唯一（本篇） |
当BSF返回400 Bad Request时，运维人员应按以下步骤排查：
flowchart TD
A["BSF返回400 Bad Request"] --> B["确认查询参数是否完整"]
B --> C{"是否携带ipDomain"}
C -->|"否"| D["补充ipDomain参数重新查询"]
C -->|"是"| E["检查绑定数据库是否有重复记录"]
D --> F{"重新查询结果"}
F -->|"200 OK"| G["问题已解决"]
F -->|"仍为400"| E
E --> H{"是否存在异常绑定"}
H -->|"是"| I["清理重复绑定记录"]
H -->|"否"| J["检查网络配置是否有误"]
I --> G
J --> K["修正配置并重建绑定"]
style D fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
style I fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
| 验证项 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|
| 用户B查询（唯一） | 200 OK | 返回唯一绑定信息 | 通过 |
| 用户A查询（不唯一） | 400 Bad Request | 返回400 | 通过 |
| 增加绑定构造重复 | 成功创建 | UE_A和UE_D绑定共存 | 通过 |
| 正负对照对比 | 行为差异明显 | 唯一/不唯一正确区分 | 通过 |
| 错误码符合协议 | 与TS 29.551一致 | 400 Bad Request | 通过 |
本篇验证了BSF在查询到会话绑定信息不唯一时的异常处理行为。测试结果表明：
BSF拒绝返回模糊结果：当同一查询条件匹配到多条绑定记录时，BSF返回400 Bad Request错误，而不是随机选择一条返回。这体现了BSF设计的严谨性——不确定的结果比没有结果更危险。
与204场景的区分：204 No Content（第14篇）表示"没有匹配"，而400 Bad Request（本篇）表示"匹配太多"。两者虽然都是查询失败，但原因不同，处理方式也不同。
ipDomain的重要性再次验证：第13篇证明了ipDomain在正常场景下区分重复IP的能力，本篇从反面证明了不使用ipDomain时的后果——绑定信息不唯一导致查询失败。
延伸思考：
运营商实际影响：在实际网络中，如果IMS语音场景出现400错误，意味着VoNR/VoLTE呼叫将无法建立策略授权，直接影响用户体验。运营商应确保ipDomain配置正确，避免出现绑定不唯一的情况。
自动化运维：建议运营商部署自动化监控，定期检查BSF中的绑定记录，发现同一IP地址存在多条绑定记录时及时告警。这可以通过定时查询BSF的绑定统计信息来实现。
协议演进：在未来的3GPP版本中，可能会引入更精细的绑定查询机制（如多条件组合查询、优先级排序等），减少绑定不唯一的发生概率。
协议参考：根据3GPP TS 29.551第5.2.2.2.4节，当
Nbsf_Management_Discovery操作根据查询参数匹配到多条PcfBinding记录时，BSF应返回400 Bad Request错误响应，错误原因中应指示"多条绑定记录匹配"。查询方收到此错误后，可以通过添加更多查询参数（如ipDomain、SUPI等）缩小查询范围，或联系网络运维人员排查重复绑定的原因。