# 5G UL CL上行分类器与BP分支点本地分流全链路信令拆解 ## 一、引言：为什么5G需要两种本地分流机制 在5G MEC（多接入边缘计算）部署中，用户面流量需要在靠近UE的边缘节点进行本地卸载，以降低端到端时延。3GPP在TS 23.501 V18.x中定义了两种核心的用户面分流功能：**UL CL（Uplink Classifier，上行分类器）**和**BP（Branching Point，分支点）**。二者虽然都服务于本地分流目标，但其工作机制、适用场景和信令流程存在本质差异。 本文基于TS 23.501 Section 5.8.2、TS 23.502 Section 4.3.2.2/4.23.5/4.23.9、TS 29.244 N4接口规范，对UL CL与BP的插入、分流、维护、删除全链路信令进行逐层拆解。 ## 二、核心概念：UL CL vs BP架构定位 ### 2.1 UL CL：基于SDF过滤器的上行分流器 UL CL是一种**UPF功能**，位于PDU Session数据路径中间节点（I-UPF），根据SMF下发的**流量过滤规则（SDF Filter）**对上行报文进行分类，将匹配特定目的IP/端口/协议的流量转发至本地PSA（PDU Session Anchor），其余流量继续发往中心PSA。 关键特征（TS 23.501 Section 5.8.2.2）： - **仅对上行流量执行过滤**（下行方向为合并转发） - UE持有**单一IP地址**，不感知UL CL的存在 - 支持IPv4和IPv6类型的PDU Session - 分流决策粒度为**SDF（Service Data Flow）级别** ### 2.2 BP：基于IPv6前缀的多归属分支点 BP是另一种UPF功能，专用于**IPv6 Multi-homing**场景。它允许一个PDU Session关联**多个IPv6前缀**，每个前缀对应不同的PSA。BP根据上行报文的**源IPv6前缀**进行路由决策。 关键特征（TS 23.501 Section 5.8.2.3）： - **双向过滤**：上行基于源前缀，下行基于目的前缀 - UE持有**多个IPv6地址/前缀**（每PSA一个） - **仅支持IPv6 PDU Session** - UE需要感知多归属，通过Router Advertisement获得多个前缀 ### 2.3 架构对比 ``` UE ──► (R)AN ──┬─ I-UPF(UL CL) ──┬─► PSA1 ──► 中心DN/Internet │ │ │ └─► PSA2 ──► 本地DN/MEC │ └─ I-UPF(BP) ────┬─► PSA1 (IPv6 Prefix-1) ──► 中心DN │ └─► PSA2 (IPv6 Prefix-2) ──► 本地MEC ``` | 对比维度 | UL CL | BP | |---------|-------|-----| | TS编号 | 23.501 §5.8.2.2 | 23.501 §5.8.2.3 | | 过滤方向 | 仅上行（DL为合并） | 双向 | | 过滤依据 | SDF Filter（目的IP/端口） | IPv6源/目的前缀 | | UE IP地址 | 单一地址 | 多个IPv6前缀 | | UE感知 | 不感知 | 感知（多前缀） | | PDU类型 | IPv4/IPv6/以太网 | 仅IPv6 | | 典型场景 | 公众MEC（商场、场馆） | 企业园区专网 | | 复杂度 | 低（UE不参与） | 高（需多前缀管理） | ## 三、UL CL插入完整信令流程 ### 3.1 触发条件 UL CL的插入由SMF决策触发（TS 23.502 Section 4.3.2.2），可能的触发源包括： 1. **UE位置变化**：UE移入/移出特定DNAI（Data Network Access Identifier）区域 2. **AF Traffic Influence**：应用功能通过NEF/PCF向SMF发送路由影响请求（TS 23.502 Section 4.3.6.2） 3. **本地策略**：SMF根据DNN、S-NSSAI、UE位置等本地配置决策 4. **PCF策略更新**：PCF通过SM Policy Association Modification下发新的PCC规则 ### 3.2 UL CL插入信令时序图 以下为UE移动触发的UL CL插入完整信令流（TS 23.502 Section 4.3.2.2 + 4.23.5）： ```mermaid sequenceDiagram participant UE participant RAN participant AMF participant SMF participant PCF participant ULCL_UPF as I-UPF(UL CL) participant PSA1 as PSA1(中心) participant PSA2 as PSA2(本地/MEC) Note over UE,PSA2: Step 0: PDU Session已建立，UE→PSA1直连 UE->>RAN: Mobility Registration Update RAN->>AMF: N2 Mobility Registration(含UserLocationInfo) AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
(UserLocationInfo, AccessType) Note over SMF: SMF检测到UE移入DNAI-2区域
决定插入UL CL和PSA2 SMF->>PCF: Npcf_SMPolicyControl_Update
(UserLocation, DNAI change) PCF-->>SMF: Policy Decision(含Traffic Steering Info) Note over SMF: SMF选择I-UPF(支持UL CL)和PSA2 SMF->>PSA2: N4 Session Establishment Request
(PDR: UE IP→PSA2, FAR→N6 Local DN) PSA2-->>SMF: N4 Session Establishment Response
(F-TEID for N9 DL) SMF->>ULCL_UPF: N4 Session Establishment Request
(PDR1: SDF→Local, FAR→PSA2
PDR2: Default, FAR→PSA1) ULCL_UPF-->>SMF: N4 Session Establishment Response
(F-TEID for N3/N9) SMF->>PSA1: N4 Session Modification Request
(更新FAR: DL→ULCL N9 tunnel) PSA1-->>SMF: N4 Session Modification Response SMF->>AMF: Nsmf_PDUSession_UpdateSMContext Response
(N2 SM Info: UL CL N3 F-TEID) AMF->>RAN: N2 PDU Session Resource Setup Request
(UL CL N3 F-TEID) RAN-->>AMF: N2 PDU Session Resource Setup Response
(RAN N3 F-TEID) AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
(RAN N3 F-TEID) SMF->>ULCL_UPF: N4 Session Modification Request
(更新Access侧F-TEID为RAN) ULCL_UPF-->>SMF: N4 Session Modification Response Note over UE,PSA2: 数据路径建立：
UE→RAN→UL CL→PSA1(中心)
UE→RAN→UL CL→PSA2(本地MEC) ``` ### 3.3 关键IE解析 #### 3.3.1 SMF→UL CL UPF的N4规则集 SMF向I-UPF（UL CL）下发两组PDR+FAR规则（TS 29.244 Section 7.5.2）： **规则组1：本地流量转发** | IE名称 | 取值 | 说明 | |--------|------|------| | PDR ID | PDR-1 | 本地流量检测规则 | | Precedence | 100 | 高优先级 | | PDI.Source Interface | ACCESS | 来自UE方向 | | PDI.UE IP Address | 10.1.1.2 | UE的IP地址 | | PDI.SDF Filter | permit out ip from any to 192.168.100.0/24 | 目的为本地DN的流量 | | FAR ID | FAR-LOCAL | 关联本地转发动作 | | FAR.Apply Action | FORW | 转发 | | FAR.Destination Interface | CORE | 核心网侧 | | FAR.Outer Header Creation | GTP-U/UDP/IPv4, TEID=0xAAA, IP=PSA2 | N9隧道至PSA2 | **规则组2：中心流量转发（Default）** | IE名称 | 取值 | 说明 | |--------|------|------| | PDR ID | PDR-2 | 默认流量规则 | | Precedence | 200 | 低优先级（兜底） | | PDI.Source Interface | ACCESS | 来自UE方向 | | PDI.UE IP Address | 10.1.1.2 | UE的IP地址 | | FAR ID | FAR-CENTRAL | 关联中心转发动作 | | FAR.Apply Action | FORW | 转发 | | FAR.Destination Interface | CORE | 核心网侧 | | FAR.Outer Header Creation | GTP-U/UDP/IPv4, TEID=0xBBB, IP=PSA1 | N9隧道至PSA1 | #### 3.3.2 PDR规则匹配逻辑（状态图） ```text stateDiagram-v2 [*] --> 收到上行报文 收到上行报文 --> 检查PDR1: 目的IP匹配本地DN? 检查PDR1: 目的IP匹配本地DN? --> 匹配: FAR-LOCAL转发至PSA2 检查PDR1: 目的IP匹配本地DN? --> 不匹配: 检查PDR2 检查PDR2 --> FAR-CENTRAL转发至PSA1 匹配: FAR-LOCAL转发至PSA2 --> [*] FAR-CENTRAL转发至PSA1 --> [*] ``` #### 3.3.3 下行合并机制 下行方向，PSA1和PSA2各自将报文通过N9隧道发往UL CL UPF。UL CL UPF根据下行PDR将两个PSA的流量合并后通过N3隧道统一转发给(R)AN→UE。这一合并操作不需要额外的过滤逻辑，因为两个PSA的下行报文都是**同一UE IP**为目的地址。 ## 四、BP分支点插入信令流程 ### 4.1 IPv6 Multi-homing PDU Session建立 BP的插入比UL CL更复杂，因为它涉及IPv6多前缀管理。TS 23.501 Section 5.6.4.3定义了Multi-homing PDU Session的建立流程。 ```mermaid sequenceDiagram participant UE participant RAN participant AMF participant SMF participant BP_UPF as I-UPF(BP) participant PSA1 as PSA1(Prefix-1) participant PSA2 as PSA2(Prefix-2) Note over UE,PSA2: PDU Session建立请求(IPv6 Multi-homing) UE->>AMF: NAS PDU Session Establishment Request
(DNN, S-NSSAI, PDU Type=IPv6) AMF->>SMF: Nsmf_PDUSession_CreateSMContext SMF->>PSA1: N4 Session Est.(PDR: Prefix-1, FAR: N6 DN1) PSA1-->>SMF: N4 Response(F-TEID, IPv6 Prefix-1) Note over SMF: SMF决策需要本地分流
选择BP UPF和PSA2 SMF->>PSA2: N4 Session Est.(PDR: Prefix-2, FAR: N6 DN2/MEC) PSA2-->>SMF: N4 Response(F-TEID, IPv6 Prefix-2) SMF->>BP_UPF: N4 Session Est.
(PDR1: Src Prefix-1→PSA1
PDR2: Src Prefix-2→PSA2) BP_UPF-->>SMF: N4 Response(F-TEID) SMF->>AMF: CreateSMContext Response
(N2 SM Info) AMF->>RAN: N2 PDU Session Resource Setup RAN-->>AMF: N2 Response AMF->>SMF: UpdateSMContext(RAN F-TEID) SMF-->>UE: NAS PDU Session Establishment Accept
(Interface ID→Prefix-1) Note over UE: UE通过Router Solicitation
获得Prefix-2 UE->>PSA1: Router Solicitation(Prefix-1链路) PSA1-->>UE: Router Advertisement(Prefix-1) Note over SMF: SMF触发PSA2侧前缀分配 SMF->>BP_UPF: N4 Modification(下发Prefix-2 RA触发) BP_UPF->>UE: Router Advertisement(Prefix-2) Note over UE,PSA2: 数据路径：
源Prefix-1→BP→PSA1→DN1
源Prefix-2→BP→PSA2→MEC ``` ### 4.2 BP的N4规则设计 BP UPF的核心过滤逻辑基于**IPv6源地址前缀**（上行）和**IPv6目的地址前缀**（下行）： | 方向 | PDR匹配条件 | FAR目标 | |------|------------|---------| | UL | Source Interface=ACCESS, Src IPv6 Prefix=2001:db8:1::/64 | → PSA1 N9 tunnel | | UL | Source Interface=ACCESS, Src IPv6 Prefix=2001:db8:2::/64 | → PSA2 N9 tunnel | | DL | Source Interface=CORE(PSA1), Dst IPv6 Prefix=2001:db8:1::/64 | → Access N3 tunnel | | DL | Source Interface=CORE(PSA2), Dst IPv6 Prefix=2001:db8:2::/64 | → Access N3 tunnel | 这种双向前缀匹配确保了：UE使用Prefix-1发出的报文经PSA1到中心DN，使用Prefix-2发出的报文经PSA2到本地MEC，且下行报文能正确返回。 ### 4.3 UE侧前缀感知与应用绑定 与UL CL不同，BP模式下UE必须明确知道多个前缀的存在，并决定应用层流量使用哪个前缀： - **URSP（UE Route Selection Policy）**：TS 23.503定义了UE如何根据应用Traffic Descriptor选择特定PDU Session或特定IPv6前缀 - **OS层面**：UE操作系统维护多个IPv6地址，应用通过`bind()`系统调用选择源地址 - **Router Advertisement**：PSA通过ICMPv6 RA消息下发前缀，BP UPF在RA路径上负责将不同PSA的RA正确传递给UE ## 五、I-SMF场景下的UL CL/BP控制 当UE移出Home-SMF服务的区域时，需要引入I-SMF（Intermediate SMF）来管理拜访地的用户面。TS 23.502 Section 4.23.9定义了I-SMF控制下的UL CL/BP插入流程。 ```mermaid flowchart TB A[UE移入新TA区域] --> B{AMF检测超出
H-SMF服务范围?} B -->|是| C[选择I-SMF] B -->|否| D[H-SMF直接管理
UL CL/BP插入] C --> E[I-SMF建立
N4会话至I-UPF/UL CL] E --> F[I-SMF通过
N16a接口通知H-SMF] F --> G[H-SMF更新PSA
N4会话FAR] G --> H[数据路径：
UE→I-UPF/UL CL→PSA1/PSA2] ``` I-SMF场景的关键差异： | 方面 | H-SMF直接管理 | I-SMF场景 | |------|-------------|-----------| | UL CL/BP选择 | H-SMF直接选择 | I-SMF选择I-UPF | | N4会话管理 | H-SMF直接与UL CL通信 | I-SMF与I-UPF建立N4 | | PSA管理 | H-SMF管理 | H-SMF仍管理PSA | | 接口 | 无额外接口 | N16a（I-SMF↔H-SMF） | | DNAI决策 | H-SMF本地策略 | I-SMF上报DNAI给H-SMF | ## 六、N4 PFCP消息IE深度解析 ### 6.1 N4 Session Establishment Request中的UL CL/BP相关IE 以TS 29.244 Section 7.5.2.2为基准，SMF向UL CL UPF发送的PFCP Session Establishment Request包含以下关键IE结构： ``` PFCP Session Establishment Request ├── Node ID (SMF标识) ├── F-SEID (SMF侧PFCP会话端点) ├── Create PDR (规则组1: 本地流量) │ ├── PDR ID = 1 │ ├── Precedence = 100 │ ├── PDI (Packet Detection Information) │ │ ├── Source Interface = ACCESS (0) │ │ ├── F-TEID (UL CL N3/N9接收TEID) │ │ ├── UE IP Address = 10.1.1.2 │ │ ├── SDF Filter │ │ │ ├── Flow Description: "permit out ip from any to 192.168.100.0/24" │ │ │ └── ToS Traffic Class: (可选) │ │ └── Application ID: (可选，用于App检测) │ ├── Outer Header Removal = GTP-U/UDP/IPv4 │ ├── FAR ID = 1 │ ├── QER ID(s) = (关联QoS规则) │ └── URR ID(s) = (关联计费规则) ├── Create FAR (FAR-1: 本地转发) │ ├── FAR ID = 1 │ ├── Apply Action = FORW (Forward) │ └── Forwarding Parameters │ ├── Destination Interface = CORE (1) │ ├── Network Instance = "local.mec.dnn" │ ├── Outer Header Creation │ │ ├── Outer Header Type = GTP-U/UDP/IPv4 │ │ ├── TEID = 0xAAA (PSA2 N9 DL TEID) │ │ └── IPv4 Address = PSA2_IP │ └── Transportation Level Marking = DSCP value ├── Create PDR (规则组2: 中心流量) │ ├── PDR ID = 2 │ ├── Precedence = 200 (低于规则组1) │ ├── PDI │ │ ├── Source Interface = ACCESS │ │ ├── F-TEID (同上) │ │ └── UE IP Address = 10.1.1.2 │ └── FAR ID = 2 ├── Create FAR (FAR-2: 中心转发) │ ├── FAR ID = 2 │ ├── Apply Action = FORW │ └── Forwarding Parameters │ ├── Destination Interface = CORE │ ├── Outer Header Creation │ │ ├── TEID = 0xBBB (PSA1 N9 DL TEID) │ │ └── IPv4 Address = PSA1_IP │ └── ... └── Create QER / URR (可选) ``` ### 6.2 BP场景的N4规则差异 BP模式下的PDI（Packet Detection Information）与UL CL有本质不同： | IE | UL CL模式 | BP模式 | |----|----------|--------| | PDI过滤字段 | SDF Filter（目的IP/端口） | UE IPv6 Prefix（源前缀） | | 匹配粒度 | 5-tuple或App ID | IPv6 /64前缀 | | 下行过滤 | 不需要（仅合并） | Dst IPv6 Prefix | | UE IP字段 | 单一IP地址 | 多个Interface ID | BP的PDI中使用**UE IP Address IE**，但设置Type=2（IPv6 prefix而非完整地址），Prefix Length通常为/64。这使得BP的过滤效率极高——仅需匹配IPv6头部的前缀字段，无需深度包检测。 ## 七、抓包识别与故障排查 ### 7.1 Wireshark抓包识别要点 **PFCP（N4）层面**： - 过滤器：`pfcp || gtpv2` - 识别UL CL插入：查找PFCP Session Establishment中同时包含两个Create PDR且Precedence不同的消息 - 关键字段：SDF Filter内容、Outer Header Creation中的目的TEID/IP - BP识别：PDI中包含IPv6 Prefix而非完整IP地址 **GTP-U（N3/N9）层面**： - 过滤器：`gtp && gtp.message == 0xff`（GTP-U用户数据） - 识别分流：同一UE IP的报文出现在两个不同的N9隧道中（TEID不同） - 验证本地分流：确认目的为192.168.100.0/24的报文被转发至PSA2的TEID **NAS层面**： - UL CL场景：NAS PDU Session Modification Command中不携带新IP地址 - BP场景：UE收到新的Router Advertisement消息（新增IPv6前缀） ### 7.2 常见故障场景 | 故障现象 | 可能原因 | 排查方法 | |---------|---------|---------| | 本地流量未分流至MEC | SDF Filter配置错误或Precedence冲突 | 检查PFCP Session Est中PDR规则 | | UE无法访问本地DN | PSA2的N6接口路由/DNS未配置 | 在PSA2上ping本地DN服务器 | | UL CL插入后全部流量中断 | PSA1的N4 FAR未更新（DL仍直连RAN） | 检查PSA1的N4 Modification | | BP场景UE未获得第二前缀 | RA消息被BP UPF拦截或未转发 | 抓包检查ICMPv6 RA | | 分流后QoS降级 | UL CL UPF未正确配置QER | 检查QER中的MBR/GBR参数 | | I-SMF场景数据面不通 | N16a接口DNAI信息未同步 | 检查I-SMF→H-SMF的N16a消息 | ## 八、设计意图与演进方向 ### 8.1 为什么设计两种机制 3GPP设计UL CL和BP双机制的核心理由： 1. **向后兼容**：UL CL模式对UE完全透明，不需要UE做任何改动。这使得运营商可以在现网UE上立即部署MEC业务。 2. **IPv6原生支持**：BP模式利用了IPv6多前缀的原生能力，为需要精确路由控制的场景（如企业园区专网）提供了更优雅的方案。 3. **分流粒度差异**：UL CL基于SDF（五元组/应用ID），可以做到应用级分流；BP基于前缀，只能做到子网级分流。 ### 8.2 R18/R19增强方向 - **TS 23.501 R18**：增强了AF对DNAI变更事件订阅能力（Event Exposure），使MEC应用能实时感知UL CL/BP的变化 - **R19增强**：引入更细粒度的Traffic Steering Control，支持基于AI/ML的动态分流决策 - **ATSSS（Access Traffic Steering, Switching, Splitting）**：与UL CL协同，实现多接入（3GPP+Non-3GPP）场景下的分流 ## 常见问题 **Q1: UL CL和BP能否同时用于同一个PDU Session？** A: 不能。根据TS 23.501 Section 5.8.2，一个PDU Session同一时刻只能使用UL CL或BP其中一种分流机制。但可以在PDU Session生命周期内从一种切换到另一种（通过PDU Session Modification）。 **Q2: UL CL插入时UE需要知道吗？** A: 不需要。这是UL CL的核心优势——UE完全不感知中间UPF的插入和删除。SMF可能通过PDU Session Modification Command通知UE新的QoS规则，但UE不知道流量在中间被分流。 **Q3: BP模式下应用如何选择使用哪个IPv6前缀？** A: 有两种方式：一是UE操作系统层面的URSP规则，根据应用ID/Traffic Descriptor自动绑定源地址；二是应用自身通过`bind()`系统调用显式指定源IPv6地址。 **Q4: UL CL删除后流量如何回退？** A: SMF执行反向操作：删除UL CL UPF的N4会话，修改PSA1的FAR使其直连RAN（恢复N3隧道），通知AMF更新N2资源。整个过程UE不感知。 **Q5: UL CL UPF能否和PSA合设？** A: 可以。在小型MEC部署中，UL CL功能可以与PSA2（本地UPF）合设在同一物理节点。此时N9隧道变成内部接口，降低时延。但UL CL与PSA1（中心UPF）通常不部署在同一位置。 ## 参考来源 1. [3GPP TS 23.501 V18.10.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123501/18.10.00_60/ts_123501v181000p.pdf) — Section 5.8.2 (UL CL/BP概念), Section 5.6.4.3 (Multi-homing), Section 6.3.3 (UPF功能) 2. [3GPP TS 23.502 V18.10.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — Section 4.3.2.2 (PDU Session Modification with UL CL), Section 4.23.5/4.23.9 (I-SMF场景) 3. [3GPP TS 29.244 — N4接口PFCP协议](https://www.etsi.org/deliver/etsi_ts/129200_129299/129244/) — Section 7.5.2 (PFCP Session Establishment), PDR/FAR IE定义 4. [free5GC UL CL Deployment Guide](https://costasgk.github.io/ulcl-traffic-steering-free5gc/) — 开源5GC实现中的UL CL动态流量引导实践 5. [华为云社区 — 5G NGC边缘业务本地分流](https://bbs.huaweicloud.com/blogs/291933) — LADN/UL CL/BP三种分流方案对比分析 --- > 本文由「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 等场景全覆盖。