在5G MEC(Multi-access Edge Computing)部署场景中,用户面流量需要在靠近UE的位置进行本地分流,以实现超低时延和对本地数据网络(Local DN)的高效访问。3GPP在TS 23.501和TS 23.502中定义了UL CL(Uplink Classifier,上行分类器)和Branching Point(分支点)两种UPF功能实体,用于在PDU会话的数据面中实现多锚点流量 Steering。
本文聚焦于UL CL插入流程(TS 23.502 Section 4.3.4.3),从SMF决策触发、N4会话建立/修改、PDR/FAR规则编排,到N3/N9隧道建立的全流程进行逐级拆解,并结合TS 29.244中PFCP协议的具体IE结构进行深度分析。
| 维度 | UL CL(上行分类器) | Branching Point(分支点) |
|---|---|---|
| TS定义 | TS 23.501 Clause 5.8.2.2 | TS 23.501 Clause 5.8.2.3 |
| 分流粒度 | 基于SDF过滤器(IP 5元组)精确匹配 | 基于UE粒度,复制全部流量 |
| 上行处理 | 匹配过滤器的上行流量转发到本地PSA | 全部上行流量复制到多个PSA |
| 下行处理 | 从多个PSA接收下行流量并合并 | 从多个PSA接收下行流量并合并 |
| 典型场景 | MEC本地分流、选择性流量Steering | IPv6 Multi-homing(多宿主) |
| PDU类型 | IPv4/IPv6/以太网类型均支持 | 仅支持IPv6 Multi-homing PDU会话 |
| UE感知 | 完全透明,UE不感知UL CL的存在 | UE感知多个IPv6前缀 |
设计意图:UL CL之所以对UE透明,是因为SMF希望通过网络侧控制面完成所有流量Steering决策,避免UE侧的复杂性——UE无需修改任何应用逻辑或IP配置,即可将特定流量(如视频流、AR/VR渲染)自动路由到边缘计算节点。
以下时序图展示了UE已建立PDU会话后,SMF决定插入UL CL和本地PSA2的完整信令流程,基于TS 23.502 Section 4.3.4.3。
sequenceDiagram
participant UE
participant RAN as (R)AN/gNB
participant AMF
participant SMF
participant ULCL as UPF(UL CL)
participant PSA1 as UPF(PSA1) 中央锚点
participant PSA2 as UPF(PSA2) 本地锚点
participant PCF
Note over UE,PCF: 阶段一:触发决策
UE->>RAN: 移动到MEC区域/触发AF请求
SMF->>SMF: 检测到DNAI变化或收到AF Influence请求<br/>决定插入UL CL + PSA2
Note over UE,PCF: 阶段二:N4会话准备
SMF->>PSA2: N4 Session Establishment Request<br/>(Create PDR + FAR for Local DN)
PSA2-->>SMF: N4 Session Establishment Response<br/>(F-TEID for N3/N9)
SMF->>ULCL: N4 Session Establishment Request<br/>(Create PDR#1: UL→PSA2 + FAR#1)<br/>(Create PDR#2: UL→PSA1 + FAR#2)<br/>(Create PDR#3: DL from PSA1 → UE + FAR#3)<br/>(Create PDR#4: DL from PSA2 → UE + FAR#4)
ULCL-->>SMF: N4 Session Establishment Response<br/>(F-TEID for N3)
SMF->>PSA1: N4 Session Modification Request<br/>(Update FAR: DL forwarding to UL CL N9)
PSA1-->>SMF: N4 Session Modification Response
Note over UE,PCF: 阶段三:N2会话修改
SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(N2 SM Info: UL CL F-TEID + QoS)
AMF->>RAN: N2 PDU Session Resource Modify<br/>(N2 SM Info + NAS PDU Session Modify)
RAN->>RAN: 建立到UL CL的新N3隧道
RAN-->>AMF: N2 PDU Session Resource Modify Response<br/>(AN Tunnel Info)
AMF->>SMF: Nsmf_PDUSession_UpdateSMContext<br/>(AN Tunnel Info)
Note over UE,PCF: 阶段四:隧道激活
SMF->>ULCL: N4 Session Modification Request<br/>(Update FAR#3/#4: AN Tunnel Info)
ULCL-->>SMF: N4 Session Modification Response
Note over UE,PCF: 数据面激活
rect rgb(230, 245, 255)
Note over UE,PSA2: 激活后的数据面路径
UE->>RAN: 上行数据包
RAN->>ULCL: N3隧道(UL CL F-TEID)
ULCL->>PSA2: [匹配本地过滤器] N9→N6→Local DN
ULCL->>PSA1: [匹配默认过滤器] N9→N6→Central DN
PSA2->>ULCL: 下行数据(来自Local DN)
PSA1->>ULCL: 下行数据(来自Central DN)
ULCL->>RAN: 合并下行数据
RAN->>UE: 下行数据
end
Note over UE,PCF: 阶段五:策略通知(可选)
SMF->>PCF: Npcf_SMPolicyControl_Update<br/>(DNAI change notification)
PCF-->>SMF: Policy Update Ack
UL CL的插入并非由单一事件触发,SMF可以从以下四条路径获得决策依据:
| 触发路径 | TS参考 | 信令接口 | 典型场景 |
|---|---|---|---|
| UE移动触发 | TS 23.502 §4.3.4.3 | N2 Handover / Path Switch | UE进入MEC服务区域 |
| AF Influence | TS 23.502 §4.3.6.2 | N5/N28 (AF→PCF→SMF) | 应用请求路由到特定DNAI |
| 本地策略触发 | TS 23.501 §5.8.2.2 | SMF内部决策 | 运营商预配置的区域规则 |
| OAM配置触发 | TS 23.501 §5.8.2 | N/A | 网管配置UL CL部署策略 |
DNAI是UL CL插入决策的核心参数,定义于TS 23.501 Clause 5.6.7。SMF通过以下逻辑判断是否需要插入UL CL:
flowchart TD
A[SMF检测到UE位置变化/AF请求] --> B{当前DNAI == 目标DNAI?}
B -->|是| C[无需插入UL CL<br/>保持当前路径]
B -->|否| D{SSC模式?}
D -->|SSC Mode 1| E[不能改变PSA<br/>通过UL CL插入实现本地分流]
D -->|SSC Mode 2| F[先释放旧PSA<br/>再建立新PSA+UL CL]
D -->|SSC Mode 3| G[先建立新PSA+UL CL<br/>再释放旧PSA]
E --> H[选择UL CL UPF<br/>选择PSA2 UPF]
F --> H
G --> H
H --> I[建立N4会话<br/>编排PDR/FAR规则]
I --> J[N2会话修改<br/>激活数据面隧道]
关键设计:SSC Mode 1场景下不能改变PSA(锚点固定),但UL CL的插入允许在不改变主锚点的前提下增加本地分流路径,这正是UL CL最常见的部署模式——在保持中心锚点的同时叠加边缘锚点。
UL CL的核心能力通过N4接口上的PFCP规则实现。以下深入分析TS 29.244定义的四大规则如何在UL CL UPF上进行编排。
flowchart LR
subgraph UL_CL_UPF["UL CL UPF规则编排"]
direction TB
subgraph PDR_Table["PDR检测表"]
PDR1["PDR#1<br/>Precedence: 100<br/>Src: ACCESS<br/>SDF: dst=10.0.0.0/8<br/>→FAR#1"]
PDR2["PDR#2<br/>Precedence: 200<br/>Src: ACCESS<br/>SDF: default<br/>→FAR#2"]
PDR3["PDR#3<br/>Precedence: 100<br/>Src: CORE(PSA1)<br/>UE IP match<br/>→FAR#3"]
PDR4["PDR#4<br/>Precedence: 100<br/>Src: CORE(PSA2)<br/>UE IP match<br/>→FAR#4"]
end
subgraph FAR_Table["FAR动作表"]
FAR1["FAR#1<br/>Action: FORWARD<br/>Dst: CORE<br/>N9→PSA2"]
FAR2["FAR#2<br/>Action: FORWARD<br/>Dst: CORE<br/>N9→PSA1"]
FAR3["FAR#3<br/>Action: FORWARD<br/>Dst: ACCESS<br/>N3→RAN"]
FAR4["FAR#4<br/>Action: FORWARD<br/>Dst: ACCESS<br/>N3→RAN"]
end
PDR1 --> FAR1
PDR2 --> FAR2
PDR3 --> FAR3
PDR4 --> FAR4
end
| IE名称 | PDR#1(本地分流UL) | PDR#2(默认UL) | PDR#3(中央DL) | PDR#4(本地DL) |
|---|---|---|---|---|
| PDR ID | 1 | 2 | 3 | 4 |
| Precedence | 100(高优先) | 200(低优先) | 100 | 100 |
| Source Interface | ACCESS | ACCESS | CORE | CORE |
| F-TEID | AN Tunnel EP | AN Tunnel EP | N9 from PSA1 | N9 from PSA2 |
| UE IP Address | UE IPv4/IPv6 | UE IPv4/IPv6 | UE IPv4/IPv6 | UE IPv4/IPv6 |
| SDF Filter | dst IP=10.0.0.0/8 | 无(通配) | 无 | 无 |
| Associated FAR | FAR#1 | FAR#2 | FAR#3 | FAR#4 |
| Associated QER | QER#1(GBR) | QER#2(Non-GBR) | QER#1 | QER#2 |
| Associated URR | URR#1(本地统计) | URR#2(中央统计) | URR#1 | URR#2 |
Precedence规则:PDR#1的Precedence=100低于PDR#2的200,意味着数值越小优先级越高。当UE的上行数据包同时匹配本地DN过滤器(10.0.0.0/8)和默认通配规则时,将优先匹配PDR#1并执行FAR#1将流量转发到本地PSA2。
| 规则维度 | SSC Mode 1+UL CL | SSC Mode 2+UL CL | SSC Mode 3+UL CL |
|---|---|---|---|
| PSA1处理 | 保持不变 | 释放后重建 | 保持至切换完成 |
| PSA2处理 | 新增本地锚点 | 替换旧锚点 | 新增锚点后过渡 |
| UL CL生命周期 | 持续存在直到UE移出MEC区域 | 短暂存在用于会话重建 | 过渡期间存在 |
| IP地址连续性 | 完全保持(单IP) | 不保持(重新分配) | 完全保持(双IP过渡) |
| UE是否感知 | 不感知 | 感知(新会话建立) | 部分感知(新IP前缀) |
| 数据面中断 | 无中断 | 有中断(毫秒级) | 无中断(make-before-break) |
SMF向UL CL UPF发送的PFCP Session Establishment Request中,核心IE按照TS 29.244 Clause 7.5.2.2编码:
PFCP Session Establishment Request
├── Node ID (SMF ID)
├── F-SEID (SMF侧PFCP会话端点)
├── Create PDR #1
│ ├── PDR ID = 1
│ ├── Precedence = 100
│ ├── PDI (Packet Detection Information)
│ │ ├── Source Interface = ACCESS (0)
│ │ ├── F-TEID = AN Tunnel Endpoint (待后续Update)
│ │ ├── UE IP Address = x.x.x.x
│ │ └── SDF Filter = "permit out ip from any to 10.0.0.0/8"
│ ├── Outer Header Removal = GTP-U/UDP/IPv4
│ ├── FAR ID = 1
│ └── QER ID = 1
├── Create FAR #1
│ ├── FAR ID = 1
│ ├── Apply Action = FORW (Forward)
│ └── Forwarding Parameters
│ ├── Destination Interface = CORE (1)
│ ├── Network Instance = "local.instance.mec"
│ └── Outer Header Creation = N9 GTP-U to PSA2 F-TEID
├── Create QER #1
│ ├── QER ID = 1
│ ├── Gate Status = OPEN
│ ├── QFI = 7 (URLLC QoS Flow)
│ ├── UL Maximum Bitrate = 100 Mbps
│ └── DL Maximum Bitrate = 100 Mbps
└── Create URR #1
├── URR ID = 1
├── Measurement Method = VOLUME
├── Reporting Triggers = VOLUME_THRESHOLD
└── Volume Threshold = 1 GB
UL CL插入后的完整数据面拓扑如下:
┌─────────────────┐
│ Central DN │ (Internet/核心网业务)
└────────┬────────┘
│ N6
┌────────▼────────┐
│ UPF (PSA1) │ ← 中央PDU会话锚点
└────────┬────────┘
│ N9 (GTP-U)
┌────────▼────────┐
┌────────│ UPF (UL CL) │────────┐
│ └────────┬────────┘ │
│ │ N3 (GTP-U) │ N9 (GTP-U)
│ ┌────────▼────────┐ │
│ │ (R)AN / gNB │ │
│ └────────┬────────┘ │
│ │ Uu │
│ ┌────────▼────────┐ │
│ │ UE │ │
│ └─────────────────┘ │
│ │
│ ┌─────────────────┐ ┌─────────▼─────────┐
│ │ UPF (PSA2) │ │ (UL CL内部路由) │
│ │ 本地锚点 │◄───┤ PDR#1匹配→FAR#1 │
│ └────────┬────────┘ │ PDR#2匹配→FAR#2──►│──PSA1
│ │ N6 └───────────────────┘
│ ┌────────▼────────┐
└─►│ Local DN │ (MEC应用服务器)
│ (Edge Server) │
└─────────────────┘
UL CL插入时,N3隧道端点从PSA1迁移到UL CL UPF。这是一个关键操作:
SMF通过Namf_Communication_N1N2MessageTransfer(TS 29.518)将UL CL的N3 F-TEID传递给AMF,再由AMF通过N2 PDU Session Resource Modify下发到gNB。gNB收到后更新下行GTP-U隧道端点为UL CL的地址。
当UE离开MEC区域或应用不再需要本地分流时,SMF执行UL CL移除流程:
sequenceDiagram
participant SMF
participant ULCL as UPF(UL CL)
participant PSA1 as UPF(PSA1)
participant PSA2 as UPF(PSA2)
participant AMF
participant RAN as (R)AN
Note over SMF,PSA2: 触发:UE移出MEC区域 / AF撤销请求
SMF->>PSA2: N4 Session Release Request
PSA2-->>SMF: N4 Session Release Response
SMF->>ULCL: N4 Session Release Request
ULCL-->>SMF: N4 Session Release Response
SMF->>PSA1: N4 Session Modification Request<br/>(Update FAR: DL→新N3直连gNB)
PSA1-->>SMF: N4 Session Modification Response<br/>(PSA1 N3 F-TEID)
SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(N2 SM: PSA1 N3 F-TEID)
AMF->>RAN: N2 PDU Session Resource Modify<br/>(更新隧道端点为PSA1)
RAN-->>AMF: N2 PDU Session Resource Modify Response
AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
Note over SMF,RAN: 数据面恢复为 UE→RAN→PSA1→Central DN
在核心网抓包中识别UL CL插入流程,可使用以下Wireshark过滤表达式:
| 场景 | Wireshark过滤器 |
|---|---|
| 捕获PFCP N4会话建立 | pfcp && pfcp.msg_type == 50 (Session Establishment Request) |
| 捕获N2会话修改 | ngap && ngap.procedureCode == 48 (PDU Session Resource Modify) |
| 捕获PDR中的SDF过滤器 | pfcp.sdf_filter |
| 捕获FAR中的目标接口 | pfcp.far && pfcp.destination_interface |
| GTP-U隧道切换 | gtp_u && gtp_u.teid == <UL_CL_FTEID> |
| 故障现象 | 可能原因 | 排错方法 |
|---|---|---|
| 本地流量仍走中央PSA | PDR Precedence配置错误(默认规则优先级高于SDF规则) | 检查PFCP中的Precedence值,确保SDF规则数值更小 |
| UL CL插入后全部断流 | N9隧道未建立(PSA1↔UL CL之间GTP-U不通) | 检查PSA1的FAR Update是否包含正确的N9 Outer Header |
| 下行数据无法到达UE | UL CL未收到AN Tunnel Info(N4 Modification未完成) | 检查N2 Response后SMF是否正确发送N4 Modification |
| QoS不生效 | QER未关联到PDR或Gate Status为CLOSED | 检查PFCP中的QER ID是否正确关联 |
| UE IP冲突 | SSC Mode 3场景新旧PSA IP分配冲突 | 检查SMF的IPAM是否正确分配了新前缀 |
| ## 8. 与其他3GPP机制的交互 |
UL CL的插入决策需要考虑网络切片信息。SMF在选择UL CL UPF和本地PSA时,需要确保所选UPF属于UE所属的S-NSSAI对应的网络切片实例。这意味着:
TS 23.502 Clause 4.3.6定义了Traffic Routing Influence机制,允许AF通过PCF影响SMF的路由决策:
routingReq包含目标DNAIstateDiagram-v2
[*] --> Normal: PDU会话建立<br/>(单PSA,无UL CL)
Normal --> UL_CL_Insertion: DNAI变化/AF请求<br/>触发UL CL插入
UL_CL_Insertion --> Dual_PSA_Active: N4建立+N2修改完成<br/>双锚点激活
Dual_PSA_Active --> Dual_PSA_Active: 持续分流<br/>本地+中央流量并行
Dual_PSA_Active --> UL_CL_Removal: UE移出MEC区域<br/>或AF撤销
UL_CL_Removal --> Normal: UL CL移除完成<br/>恢复单锚点
Dual_PSA_Active --> PSA_Relocation: SSC Mode 3<br/>PSA切换
PSA_Relocation --> Dual_PSA_Active: 新PSA建立<br/>旧PSA保持
PSA_Relocation --> Normal: 旧PSA释放<br/>UL CL移除
Q1: UL CL和Branching Point的核心区别是什么?在什么场景下选择哪个?
A: UL CL基于SDF过滤器进行精确的流量匹配和分流,适用于需要将特定应用流量(如访问本地服务器的流量)路由到边缘DN的场景。Branching Point则基于UE粒度复制所有流量到多个PSA,主要用于IPv6 Multi-homing场景,UE需要同时拥有多个IPv6前缀。实际部署中,MEC本地分流几乎全部使用UL CL方案。
Q2: UL CL插入时,UE的IP地址会改变吗?
A: 不会。UL CL对UE完全透明,UE的IP地址和PDU会话参数均不改变。这是因为UL CL工作在UPF的用户面,仅修改了GTP-U隧道的转发路径,NAS层的PDU会话参数保持不变。这也是UL CL方案相比SSC Mode 2(需要重建PDU会话)的最大优势。
Q3: UL CL插入失败会导致正在进行的会话中断吗?
A: 设计上不会。SMF在UL CL插入流程中采用"先建后切"策略:先完成所有N4会话建立和规则配置,最后才通过N2会话修改切换gNB的N3隧道端点。如果在N4阶段失败,SMF不会触发N2修改,原有路径不受影响。如果N2修改失败,SMF会回滚所有N4会话变更。
Q4: 一个PDU会话可以插入多个UL CL吗?
A: 理论上支持。TS 23.501 Clause 5.8.2.2允许PDU会话数据路径中存在多个UL CL,形成级联分流。但实际部署中极少使用,因为每增加一个UL CL就增加一跳N9转发,会增加端到端时延。典型部署是单个UL CL连接一个中央PSA和一个或多个本地PSA。
Q5: 如何在抓包中区分经过UL CL的数据包和直连PSA的数据包?
A: 关键是观察GTP-U的TEID(Tunnel Endpoint Identifier)。经过UL CL的数据包的GTP-U外层TEID为UL CL UPF分配的F-TEID,而直连PSA的数据包使用PSA直接分配的F-TEID。通过对比N4 Session Establishment Response中返回的F-TEID和实际数据包中的TEID,可以确定数据路径是否经过UL CL。
本文由「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 等场景全覆盖。
