在5G MEC(Multi-access Edge Computing)部署场景中,一个核心需求是:UE的同一个PDU Session中的业务流量,需要根据目的地址被智能地分流到不同的数据网络——本地边缘应用流量去往MEC平台(低时延),普通互联网流量继续去往中心DN。3GPP在TS 23.501 Section 5.6.7和TS 23.502 Section 4.3.5中定义了UL CL(Uplink Classifier,上行分类器)机制来解决这个问题。
UL CL的本质是UPF的一种功能角色。它不是一个新的网元,而是SMF通过PFCP(N4接口)在某个UPF上配置的流量分类与转发规则集合。当UPF被配置了UL CL功能后,它会:
这是协议开发工程师最常混淆的概念。3GPP在TS 23.501 Section 5.6.7中明确定义了两种分流机制:
| 对比维度 | UL CL(上行分类器) | BP(分支点) |
|---|---|---|
| 定义章节 | TS 23.501 §5.6.7.2 | TS 23.501 §5.6.7.3 |
| 分流依据 | 业务流过滤器(SDF Filter),基于目的IP/端口 | IPv6源地址前缀(Source Prefix) |
| 地址要求 | 单一IPv4或IPv6地址即可 | 需要多个IPv6前缀(多归属) |
| PDU Session类型 | IPv4、IPv6、IPv4v6、Ethernet | 仅IPv6多归属(Multi-homing) |
| UE感知 | UE无感知UL CL的存在,仅SMF/UPF层面操作 | UE需获知额外的IPv6前缀(通过RA消息) |
| 协议开销 | 较低,无需UE参与 | 较高,需要PDU Session Modification通知UE |
| 典型场景 | MEC本地分流、企业园区 | 需要UE自主选择路径的场景 |
设计意图:UL CL机制的精妙之处在于"对UE透明"——UE无需知道UL CL的存在,不涉及任何NAS信令变更,所有分流决策完全由SMF通过PFCP在用户面完成。这极大地简化了终端侧实现复杂度。
以下信令流基于TS 23.502 Section 4.23.9.1(Addition of a PDU Session Anchor and Branching Point or UL CL controlled by SMF)和Section 4.3.6(AF influence on traffic routing):
sequenceDiagram
participant UE
participant RAN as (R)AN/gNB
participant AMF
participant SMF
participant PCF
participant ULCL as UL CL UPF
participant PSA1 as PSA-1<br/>(Central UPF)
participant PSA2 as PSA-2<br/>(Local/Edge UPF)
Note over UE,PSA1: 阶段1: 初始PDU Session已建立(仅PSA-1)
Note over SMF,PCF: 阶段2: SMF决策插入UL CL
SMF->>PCF: Npcf_SMPolicyControl_Update<br/>(获取路由策略/DNAI信息)
PCF-->>SMF: 200 OK + Policy Update<br/>(含Traffic Steering Policy)
Note over SMF,PSA2: 阶段3: 为本地DN建立PSA-2的N4会话
SMF->>PSA2: PFCP Session Establishment Request<br/>(Create PDR + FAR + QER)
PSA2-->>SMF: PFCP Session Establishment Response<br/>(F-TEID for DL)
Note over SMF,ULCL: 阶段4: 配置UL CL UPF(插入分流规则)
SMF->>ULCL: PFCP Session Modification Request<br/>(Create PDR: SDF→Local DN +<br/>Create FAR: Forward→PSA2 +<br/>Update FAR: Default→PSA1)
ULCL-->>SMF: PFCP Session Modification Response
Note over SMF,PSA1: 阶段5: 更新PSA-1下行隧道
SMF->>PSA1: PFCP Session Modification Request<br/>(Update FAR: DL F-TEID指向UL CL)
PSA1-->>SMF: PFCP Session Modification Response
Note over UE,RAN: 阶段6: 数据面分流生效
UE->>RAN: UL Data: 本地业务<br/>(目的IP=Edge App Server)
RAN->>ULCL: GTP-U (N3隧道)
ULCL->>PSA2: 匹配SDF Filter →<br/>转发到Local DN (N9隧道)
PSA2->>MEC App: 本地数据网络
UE->>RAN: UL Data: 互联网业务<br/>(目的IP=Internet)
RAN->>ULCL: GTP-U (N3隧道)
ULCL->>PSA1: 不匹配本地Filter →<br/>默认转发到Central DN (N9隧道)
PSA1->>Internet: 互联网数据网络
Note over PSA1,ULCL: 下行方向合并
PSA2->>ULCL: DL Data (N9)
PSA1->>ULCL: DL Data (N9)
ULCL->>RAN: 合并后统一转发 (N3)
RAN->>UE: DL Data
SMF在以下任何一种条件下触发UL CL的插入。3GPP在TS 23.502 Section 4.3.5和Section 4.3.6中定义了三种主要触发路径:
flowchart TD
A[SMF决策点:<br/>是否插入UL CL?] --> B{触发条件判断}
B -->|触发1| C[AF Influence on Traffic Routing<br/>TS 23.502 §4.3.6<br/>MEC应用通过NEF/PCF请求路由]
B -->|触发2| D[UE移动性触发<br/>TA变更/Cell变更<br/>UE进入新的DNAI服务区]
B -->|触发3| E[SMF本地策略/订阅数据<br/>基于DNN+S-NSSAI<br/>预配置的路由规则]
C --> F[PCF下发SM Policy<br/>含Traffic Steering Decision<br/>DNAI + Routing Info]
D --> G[SMF检测DNAI变更<br/>旧DNAI→新DNAI]
E --> H[SMF查询UDM订阅数据<br/>获取本地路由策略]
F --> I[SMF选择新的Local PSA-2<br/>基于DNAI和UPF拓扑]
G --> I
H --> I
I --> J[建立PSA-2的PFCP会话]
J --> K[配置UL CL分流规则]
K --> L[更新PSA-1下行隧道]
L --> M[可选:通知AF DNAI变更]
触发1:AF Influence on Traffic Routing(TS 23.502 §4.3.6)
这是MEC场景中最常见的触发方式。当MEC平台上的应用(AF)需要将特定UE的流量路由到本地边缘节点时:
触发2:UE移动性(DNAI变更)
当UE从DNAI-1服务区移动到DNAI-2服务区时(例如从MEC站点A移动到MEC站点B),SMF检测到跟踪区变更(TA Change),触发UL CL重定位(Relocation)流程。这在TS 23.502 Section 4.23.9.2中定义。
触发3:SMF本地策略
SMF基于预配置的策略规则(如特定S-NSSAI+DNN组合始终需要本地分流)或UDM中的订阅数据,在PDU Session Establishment阶段即决定插入UL CL。
UL CL机制的核心承载协议是PFCP(Packet Forwarding Control Protocol),定义在TS 29.244中。SMF通过PFCP在UPF上创建四类核心规则:PDR、FAR、QER、URR。
SMF向Local PSA-2发起PFCP Session Establishment:
flowchart LR
subgraph SMF发送的PFCP Session Est Req
A1[Create PDR 1<br/>PDR ID=1<br/>Precedence=100<br/>PDI: SrcIface=ACCESS<br/>UE IP Addr<br/>F-TEID: UL CL→PSA2<br/>SDF Filter: permit out<br/>ip to 10.1.0.0/16] --> A2[Create FAR 1<br/>FAR ID=1<br/>Action=FORWARD<br/>DstIface=CORE<br/>Network Instance:<br/>local-dn.mec]
A2 --> A3[Create QER 1<br/>QER ID=1<br/>QFI=7<br/>Gate Status=OPEN<br/>UL/DL MBR/GMBR]
A3 --> A4[Create URR 1<br/>URR ID=1<br/>Method=VOLUME<br/>Volume Threshold]
end
subgraph PSA-2返回的Response
B1[Cause=SUCCESS] --> B2[Created PDR 1<br/>F-TEID for DL<br/>TEID=0xA1B2C3D4<br/>IP=192.168.2.1]
end
关键IE解析:
| IE名称 | 字段 | 说明 | TS 29.244章节 |
|---|---|---|---|
| PDR | PDR ID | 标识唯一的包检测规则 | §7.5.2.1 |
| Precedence | 规则优先级,数值越小优先级越高 | §7.5.2.2 | |
| PDI (Packet Detection Information) | 包检测信息,定义匹配条件 | §7.5.2.2 | |
| Source Interface | ACCESS(上行来自UE)/ CORE(下行来自DN) | §8.2.2 | |
| UE IP Address | 匹配特定UE的IP地址 | §8.2.23 | |
| F-TEID | GTP隧道端点标识,标识N9隧道的上行TEID | §8.2.30 | |
| SDF Filter | 业务流过滤器,五元组规则 | §8.2.39 | |
| FAR | Apply Action | FORWARD/DROP/BUFFER/NOCHECK | §7.5.3.1 |
| Destination Interface | CORE侧(发往DN)或ACCESS侧(发往UE) | §8.2.2 | |
| Outer Header Creation | 创建GTP-U外层头(N9隧道封装) | §8.2.31 | |
| QER | QFI (QoS Flow Identifier) | 5QI对应的QoS流标识 | §8.2.35 |
| Gate Status | OPEN/CLOSE,控制流量通过/阻断 | §7.5.4.1 | |
| URR | Measurement Method | VOLUME/DURATION/EVENT等计费方法 | §7.5.6.1 |
这是UL CL机制的最关键步骤——SMF通过PFCP Session Modification在UL CL UPF上配置分流规则:
规则1:匹配本地业务的PDR+FAR(新增)
Create PDR:
PDR ID = 2
Precedence = 50 ← 高优先级,先于默认规则匹配
PDI:
Source Interface = ACCESS ← 检测上行流量
UE IP Address = 10.0.1.5 ← 匹配特定UE
SDF Filter = "permit out ip from 10.0.1.5 to 10.1.0.0/16"
← 目的地址为本地DN网段
Outer Header Removal = GTP-U/IPv4
Create FAR:
FAR ID = 2
Apply Action = FORWARD
Forwarding Parameters:
Destination Interface = CORE
Outer Header Creation:
GTP-U IPv4
TEID = 0xA1B2C3D4 ← PSA-2在步骤3中返回的DL F-TEID
IP Address = 192.168.2.1 ← PSA-2的N9接口IP
规则2:默认转发到PSA-1的FAR(修改原有FAR)
Update FAR:
FAR ID = 1 ← 修改PDU Session建立时创建的默认FAR
Apply Action = FORWARD
Forwarding Parameters:
Destination Interface = CORE
Outer Header Creation:
GTP-U IPv4
TEID = 0x11111111 ← PSA-1的DL F-TEID
IP Address = 10.10.1.1 ← PSA-1的N9接口IP
flowchart TD
subgraph PFCP Session Modification Request
A[Header<br/>S=1, MP=0<br/>SEID=0x12345678] --> B[Update FAR<br/>FAR ID=1]
B --> C[Create PDR<br/>PDR ID=2]
C --> D[Create FAR<br/>FAR ID=2]
D --> E[Apply Action<br/>FORWARD]
D --> F[Forwarding Parameters<br/>IE Group]
F --> F1[Destination Interface<br/>CORE=0]
F --> F2[Outer Header Creation<br/>GTP-U IPv4]
F2 --> F2a[TEID=0xA1B2C3D4]
F2 --> F2b[IP=192.168.2.1]
C --> G[PDI IE Group]
G --> G1[Source Interface<br/>ACCESS=1]
G --> G2[UE IP Address<br/>10.0.1.5]
G --> G3[SDF Filter<br/>permit out ip to 10.1.0.0/16]
G --> G4[F-TEID<br/>N3上行隧道标识]
end
UE发送上行数据包 → gNB封装GTP-U(N3) → UL CL UPF收到
│
├── 匹配PDR-2(高优先级Precedence=50)
│ ├── SDF Filter: 目的IP ∈ 10.1.0.0/16?
│ ├── YES → 应用FAR-2 → 封装N9 GTP-U(Teid=A1B2C3D4) → PSA-2 → MEC App
│ └── NO → 不匹配,继续检查下一规则
│
└── 匹配PDR-1(低优先级Precedence=100,默认规则)
├── 匹配所有其他上行流量
└── 应用FAR-1 → 封装N9 GTP-U(Teid=11111111) → PSA-1 → Internet
关键设计:PDR的Precedence决定了规则匹配的优先顺序。本地业务规则的Precedence值更小(优先级更高),确保本地流量优先匹配。不匹配任何特定规则的流量落入默认规则,转发到中心PSA-1。
MEC App下行 → PSA-2 → 封装N9 GPT-U(Teid=ULCL_DL) → UL CL UPF
Internet下行 → PSA-1 → 封装N9 GPT-U(Teid=ULCL_DL) → UL CL UPF
│
UL CL统一解封装N9
│
封装N3 GTP-U(Teid=gNB_N3)
│
→ gNB → UE
UL CL在下行方向扮演"汇聚点"角色:来自PSA-1和PSA-2的下行数据流都终结于UL CL,UL CL统一通过N3隧道转发给(R)AN。
3GPP定义了三种UL CL插入场景,对应不同的信令路径:
| 场景 | TS 23.502章节 | 触发方式 | 是否需要N2/NAS信令 |
|---|---|---|---|
| SMF控制 | §4.23.9.1 | SMF主动决策 | 通常不需要(PFCP only) |
| I-SMF控制 | §4.23.9 | UE移动到新I-SMF服务区,I-SMF插入 | 需要N2接口更新 |
| AF触发 | §4.3.6 | AF通过PCF影响路由策略 | 通常不需要 |
flowchart TB
subgraph 场景A: SMF主动插入
A1[SMF检测到:<br/>UE进入MEC服务区<br/>或策略匹配] --> A2[SMF选择PSA-2<br/>建立PFCP会话]
A2 --> A3[SMF配置UL CL<br/>PFCP Modification]
A3 --> A4[纯PFCP操作<br/>无需N2/NAS信令]
end
subgraph 场景B: I-SMF插入
B1[UE移动到新的<br/>I-SMF服务区] --> B2[AMF选择新I-SMF<br/>触发PDU Session Mod]
B2 --> B3[I-SMF插入UL CL<br/>+ 新PSA]
B3 --> B4[涉及N2信令:<br/>N2 SM Info Update<br/>N9隧道切换]
end
subgraph 场景C: AF触发路由
C1[MEC应用AF请求<br/>流量路由到边缘节点] --> C2[NEF/PCF下发策略<br/>DNAI+路由信息]
C2 --> C3[SMF执行UL CL插入<br/>PFCP操作]
C3 --> C4[可选:DNAI变更<br/>通知AF]
end
当UE在移动过程中跨越不同的DNAI(Data Network Access Identifier)服务区域时,需要执行Edge Relocation(边缘重定位)流程。这在TS 23.548 Section 6.3中有详细定义。
SMF → PCF: Npcf_SMPolicyControl_UpdateNotify
├── Notification URI
├── DNAI = "edge-site-B" ← 新DNAI
└── AF notification correlation ID
PCF → AF: Npcf_PolicyAuthorization_Notify
├── DNAI change
├── New DNAI = "edge-site-B"
└── Target App relocation info
设计意图:DNAI通知机制实现了网络与应用的联动——当网络侧决定将流量切换到新的边缘节点时,应用侧也能同步迁移服务实例,确保业务连续性。
| 步骤 | 接口 | 协议 | 过滤条件 | 关键字段 |
|---|---|---|---|---|
| SMF→PSA2 PFCP Est | N4 | PFCP | pfcp.message_type == 50 |
Create PDR含SDF Filter |
| PSA2→SMF PFCP Est Resp | N4 | PFCP | pfcp.message_type == 51 |
Cause=Success, F-TEID |
| SMF→ULCL PFCP Mod | N4 | PFCP | pfcp.message_type == 52 |
Create PDR+Create FAR |
| SMF→PSA1 PFCP Mod | N4 | PFCP | pfcp.message_type == 52 |
Update FAR |
| UL CL生效后上行分流 | N9 | GTP-U | gtp.teid == 0xA1B2C3D4 |
目的IP=10.1.x.x |
| UL CL默认上行 | N9 | GTP-U | gtp.teid == 0x11111111 |
目的IP=非本地 |
Wireshark/TShark显示过滤器:
# 过滤所有PFCP Session相关消息
pfcp && pfcp.seid == 0x12345678
# 过滤包含SDF Filter的PFCP消息
pfcp.sdf_filter
# 过滤特定TEID的GTP-U隧道
gtp.teid == 0xA1B2C3D4
| 故障现象 | 可能原因 | 排查方法 |
|---|---|---|
| 本地业务流量未分流到MEC | UL CL上PDR的SDF Filter配置错误 | 检查PFCP Mod消息中的SDF Filter语法 |
| PDR Precedence设置不当 | 确认本地业务PDR优先级高于默认PDR | |
| 分流后上行正常但下行不通 | FAR中Outer Header Creation的TEID/IP错误 | 对比PSA-2返回的F-TEID与UL CL FAR中的值 |
| PSA-2的下行FAR未正确配置Destination Interface | 检查PSA-2的FAR,DstIface应为CORE | |
| UL CL插入后所有流量中断 | 默认FAR被错误修改为DROP而非FORWARD | 检查Update FAR消息的Apply Action |
| N9隧道端点IP/TEID不匹配 | 用gping/ping检测N9隧道连通性 | |
| DNAI变更后业务中断 | 新PSA-2'的PFCP会话建立失败 | 检查PFCP Est Response的Cause值 |
| 旧PSA-2删除过早,数据面还在转发 | 确认SMF是否等待新隧道就绪后才删旧会话 | |
| ## 九、UL CL与LADN/DNN/URSP四种分流方式对比 |
5G系统提供了四种本地分流技术,各有适用场景:
| 对比维度 | UL CL | LADN | 专用DNN | URSP |
|---|---|---|---|---|
| 定义章节 | TS 23.501 §5.6.7 | TS 23.501 §5.6.5 | TS 23.501 §5.6.2 | TS 23.503 §6.6 |
| PDU Session数量 | 1个(多锚点) | 1个(限定区域) | 需要1个新PDU Session | 需要多个PDU Session |
| UE感知 | 完全透明 | 知道LADN DNN | 知道DNN名称 | 知道路由规则 |
| 分流粒度 | 五元组级别(精细) | DNN级别(粗粒度) | DNN级别 | 应用级别 |
| UE移动性 | 支持DNAI重定位 | 仅LADN服务区内有效 | 跟随PDU Session | 跟随PDU Session |
| 适用场景 | MEC本地分流、园区网 | 区域性本地服务 | 企业专网 | 多应用差异化路由 |
| 信令复杂度 | 中(PFCP为主) | 低 | 低 | 高(涉及多个PDU Session) |
| 时延优化 | 优秀(本地PSA直接接入) | 良好 | 良好 | 取决于PDU Session路由 |
Q1: UL CL和Branching Point能否同时使用? A: 不能。3GPP规定同一个PDU Session中只能选择其中一种。对于IPv4 PDU Session,只能使用UL CL;对于IPv6多归属场景,可以选择BP(基于源前缀分流)或UL CL(基于SDF Filter分流)。实际部署中UL CL更为常见,因为不要求UE感知。
Q2: 一个PDU Session最多可以插入几个UL CL和几个PSA? A: 3GPP未规定硬性上限。实际部署中,运营商通常限制为1个UL CL + 最多3-4个PSA(1个Central + 2-3个Local)。每增加一个PSA,SMF需要维护额外的PFCP会话和N9隧道,增加控制面复杂度。
Q3: UL CL插入是否影响正在进行的业务? A: 通常不影响。UL CL插入通过PFCP Modification完成,属于纯用户面操作。SMF会确保新规则生效后再切换数据面路径,避免丢包。但在极端情况下(如N9隧道端点配置错误),可能导致短暂的业务中断。
Q4: UL CL能否用于漫游场景的本地分流? A: 可以但有限制。在LBO(Local Breakout)漫游模式下,V-PLMN的SMF可以插入UL CL将流量分流到V-PLMN的本地DN。但在HR(Home Routed)模式下,由于PDU Session锚点在H-PLMN,V-PLMN无法插入UL CL。TS 23.502 Section 4.23.9定义了I-SMF场景下的处理方式。
Q5: UL CL如何与网络切片(Network Slicing)协同? A: UL CL的分流策略可以基于S-NSSAI进行差异化配置。不同切片的PDU Session可以使用不同的UL CL规则:例如URLLC切片的UL CL直接分流到工厂内网(超低时延),而eMBB切片的UL CL分流到边缘CDN(内容缓存)。SMF在选择PSA时会同时考虑S-NSSAI和DNAI的约束。
本文由「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 等场景全覆盖。
