在5G网络中,Multi-access Edge Computing(MEC) 要求将用户面流量"就近"路由到部署在边缘的计算平台,以实现超低时延和本地化数据处理。3GPP为此定义了一套完整的用户面流量分流机制,其核心功能实体是Uplink Classifier(UL CL)——上行分类器,以及与之对偶的Branching Point(BP)——分支点。
这套机制并非孤立存在,而是由多份3GPP规范共同定义:
| 规范编号 | 核心章节 | 定义内容 |
|---|---|---|
| TS 23.501 | Section 5.6.7, 5.13 | UL CL/BP架构模型与边缘计算能力框架 |
| TS 23.502 | Section 4.3.5, 4.3.6 | PDU Session Modification过程中UL CL插入/移除的信令流程 |
| TS 23.503 | Section 6.1.2, 6.2 | AF对流量路由的影响策略(PCC Rule中的Traffic Steering Policy) |
| TS 23.548 | Section 6, 6.3 | 边缘计算增强,包括Edge Relocation和EHE(Edge Hosting Environment) |
| TS 29.244 | Section 7.5 | N4接口PFCP协议中UL CL/BP相关的PDR/FAR/QER定义 |
UL CL和BP都是UPF的功能特性,但应用场景和协议栈支持有所不同:
┌─────────────────────────────────────────────────────────────────┐
│ UL CL vs BP 架构对比 │
├───────────────────┬──────────────────┬──────────────────────────┤
│ 特性 │ UL CL │ Branching Point │
├───────────────────┼──────────────────┼──────────────────────────┤
│ 适用PDU Session类型│ IPv4/IPv6/Ethernet│ 仅Multi-homed IPv6 │
├───────────────────┼──────────────────┼──────────────────────────┤
│ 分流方向 │ 上行分类 │ 上下行双向分支 │
├───────────────────┼──────────────────┼──────────────────────────┤
│ UE地址数量 │ 单一IP地址 │ 多个IPv6 Prefix │
├───────────────────┼──────────────────┼──────────────────────────┤
│ PSA连接方式 │ N9隧道到多个PSA │ N9隧道到多个PSA │
├───────────────────┼──────────────────┼──────────────────────────┤
│ 典型场景 │ MEC本地分流 │ IPv6多宿主 + MEC │
├───────────────────┼──────────────────┼──────────────────────────┤
│ 过滤规则 │ 基于PDR的UL分类 │ 基于IPv6 Prefix路由 │
└───────────────────┴──────────────────┴──────────────────────────┘
设计意图:UL CL方案保持UE侧IP地址不变,对UE完全透明——UE无需感知UL CL的存在。这是3GPP刻意为之的设计:分流逻辑完全由网络侧(SMF+UPF)控制,降低了UE实现的复杂度。
DNAI(DN Access Identifier) 是TS 23.501 Section 5.6.7引入的逻辑标识,用于标识UPF到Data Network的接入点位置。每个PSA UPF关联一个DNAI值,当SMF决定将流量从边缘站点A迁移到边缘站点B时,本质上就是一次DNAI Change(DNAI重定位)。
DNAI重定位的触发条件包括: - UE移动导致地理位置变化(如从MEC站点1覆盖区移至站点2) - AF通过NEF/PCF请求流量路由变更 - SMF本地策略触发(如UPF负载均衡、O&M操作)
以下流程基于TS 23.502 Section 4.3.5.2(SMF发起的PDU Session Modification)和TS 23.548 Section 6.2(Edge Computing Enabler)综合绘制,描述一个已在中心UPF(PSA1)建立PDU Session的UE,因进入MEC覆盖区而触发UL CL插入的完整过程:
sequenceDiagram
participant UE
participant RAN as (R)AN
participant AMF
participant SMF
participant PCF
participant ULCL as UL CL UPF<br/>(I-UPF)
participant PSA1 as PSA1 UPF<br/>(中心锚点)
participant PSA2 as PSA2 UPF<br/>(边缘锚点)
participant AF as AF/MEP
Note over UE,AF: 阶段1: 触发UL CL插入(AF发起流量路由请求)
AF->>PCF: Npcf_PolicyAuthorization<br/>AF请求更新Traffic Routing<br/>(Target DNAI=Edge-Site-A)
PCF->>SMF: Npcf_SMPolicyControl_UpdateNotify<br/>PCC Rule含Traffic Steering Policy<br/>+ 目标DNAI信息
Note over UE,AF: 阶段2: SMF决策与UPF选择
SMF->>SMF: 根据DNAI选择UL CL UPF<br/>和PSA2(边缘UPF)<br/>验证UPF支持UL CL能力
Note over UE,AF: 阶段3: N4会话建立(新UPF)
SMF->>ULCL: N4 Session Establishment Request<br/>PDR(UL CL规则) + FAR(分流动作)<br/>+ QER(QoS执行规则)
ULCL-->>SMF: N4 Session Establishment Response<br/>F-TEID(UL CL N3/N9地址)
SMF->>PSA2: N4 Session Establishment Request<br/>PDR(边缘DN匹配) + FAR(转发到DN)<br/>+ Usage Reporting Rule
PSA2-->>SMF: N4 Session Establishment Response<br/>F-TEID(PSA2 N9地址)
Note over UE,AF: 阶段4: N4会话修改(已有UPF)
SMF->>ULCL: N4 Session Modification Request<br/>更新FAR: DL到UE经N3隧道
ULCL-->>SMF: N4 Session Modification Response
SMF->>PSA1: N4 Session Modification Request<br/>更新FAR: UL到DN + DL到UL CL<br/>添加到PSA2的转发隧道
PSA1-->>SMF: N4 Session Modification Response
SMF->>RAN: N2 SM Information<br/>含新UL CL的N3 F-TEID<br/>(PDU Session Resource Setup)
Note over UE,AF: 阶段5: RAN隧道切换
RAN->>RAN: 切换UL隧道到UL CL UPF
RAN-->>AMF: N2 SM Ack<br/>含新RAN侧N3 F-TEID
AMF->>SMF: Namf_Communication_N1N2MessageTransfer ACK<br/>含RAN N3 F-TEID
SMF->>ULCL: N4 Session Modification Request<br/>更新RAN侧N3 F-TEID
ULCL-->>SMF: N4 Session Modification Response
Note over UE,UE: 阶段6: UE通知(可选)
SMF->>UE: PDU Session Modification Command<br/>(NAS消息, 经AMF转发)<br/>可能含QoS Rule更新
UE-->>SMF: PDU Session Modification Command ACK
Note over UE,AF: 阶段7: DNAI Change通知
SMF->>PCF: Npcf_SMPolicyControl_Update<br/>通知DNAI Change事件
PCF->>AF: Npcf_PolicyAuthorization_Notify<br/>通知DNAI从Central变更为Edge-Site-A
Note over UE,AF: 数据面路径: UE→RAN→UL CL→PSA2→边缘DN<br/> UE→RAN→UL CL→PSA1→中心DN
阶段1:触发源——AF通过PCF影响流量路由
AF(Application Function,可以是MEC平台MEP/MEAO)调用Npcf_PolicyAuthorization服务,在AppSessionContext中指定目标DNAI和流量描述信息(Traffic Descriptor)。PCF将其转化为PCC Rule中的Traffic Steering Policy Identifier,通过Npcf_SMPolicyControl_UpdateNotify下发给SMF。
关键IE:
| IE名称 | 来源 | 说明 |
|---|---|---|
trafficSteeringPolIdDl |
PCF→SMF | 下行流量导向策略ID,引用预配置的UL CL分流规则 |
routeToLocs[i].dnai |
PCF→SMF | 目标DNAI值,标识边缘接入点 |
routeToLocs[i].routeProfId |
PCF→SMF | 路由配置文件ID,包含QoS和N6/N19接口参数 |
afAppId |
AF→PCF | 应用标识,用于匹配UL CL的PDR过滤规则 |
trafficFilters |
AF→PCF | IP 5-tuple流量过滤器(源/目的IP、端口、协议) |
阶段2:SMF决策
SMF收到PCF的PCC Rule后执行:
1. 根据dnai查询NRF或本地配置,选择支持该DNAI的UPF作为PSA2
2. 选择一个支持UL CL功能的UPF作为I-UPF(可以是独立UPF或与PSA合一)
3. 验证目标UPF的UL CL能力标志(upFunctionFeatures中的ULCL比特位)
阶段3:N4会话建立
SMF分别与UL CL UPF和PSA2建立N4会话。N4接口使用PFCP协议(TS 29.244),核心是下发三类规则:
sourceInterface=ACCESS和UL方向流量过滤器graph TB
subgraph "N4 Session: UL CL UPF规则结构"
PDR1["PDR#1<br/>Source Interface: ACCESS<br/>Filter: 边缘App流量<br/>Priority: 100"]
PDR2["PDR#2<br/>Source Interface: ACCESS<br/>Filter: Any<br/>Priority: 200"]
FAR1["FAR#1<br/>Action: Forward<br/>Destination: PSA2 N9<br/>Tunnel: GTP-U"]
FAR2["FAR#2<br/>Action: Forward<br/>Destination: PSA1 N9<br/>Tunnel: GTP-U"]
QER1["QER#1<br/>QFI: 7<br/>Gate Status: Open<br/>MBR: 100Mbps"]
PDR1 -->|"关联"| FAR1
PDR1 -->|"关联"| QER1
PDR2 -->|"关联"| FAR2
end
subgraph "N4 Session: PSA2 UPF规则结构"
PDR3["PDR#1<br/>Source Interface: CORE<br/>Filter: 边缘DN响应<br/>Destination: UE IP"]
FAR3["FAR#1<br/>Action: Forward<br/>Destination: UL CL N9<br/>Encap: GTP-U"]
URR1["URR#1<br/>Method: Volume+Time<br/>Report Trigger: Periodic<br/>Threshold: 1GB"]
PDR3 -->|"关联"| FAR3
PDR3 -->|"关联"| URR1
end
style PDR1 fill:#e1f5fe
style PDR2 fill:#fff3e0
style FAR1 fill:#c8e6c9
style FAR2 fill:#ffecb3
当UE在移动过程中跨越不同MEC站点的覆盖区域时,需要将边缘锚点从PSA2(站点A)迁移到PSA3(站点B)。这个过程称为DNAI Relocation,定义在TS 23.502 Section 4.3.5.3和TS 23.548 Section 6.3。
DNAI重定位与SSC(Session and Service Continuity)Mode密切相关:
stateDiagram-v2
[*] --> SinglePSA: PDU Session建立<br/>(SSC Mode 1/2/3)
SinglePSA --> ULCL_Inserted: SMF触发<br/>UL CL插入<br/>(SSC Mode 1 or 3)
state SinglePSA {
[*] --> PSA1_Only
note right of PSA1_Only: 数据路径:<br/>UE→PSA1→中心DN
}
state ULCL_Inserted {
[*] --> ULCL_PSA1_PSA2
note right of ULCL_PSA1_PSA2: 数据路径:<br/>UE→UL CL→PSA1→中心DN<br/>UE→UL CL→PSA2→边缘DNAI-A
}
ULCL_Inserted --> DNAI_Relocating: DNAI Change触发<br/>(UE移动到站点B)<br/>(SSC Mode 3)
state DNAI_Relocating {
[*] --> MakeBeforeBreak
note right of MakeBeforeBreak: 双锚点并存:<br/>PSA2(DNAI-A) + PSA3(DNAI-B)<br/>数据转发隧道建立
}
DNAI_Relocating --> ULCL_Reconfigured: 旧锚点PSA2释放<br/>N4 Session Release
state ULCL_Reconfigured {
[*] --> ULCL_PSA1_PSA3
note right of ULCL_PSA1_PSA3: 数据路径:<br/>UE→UL CL→PSA1→中心DN<br/>UE→UL CL→PSA3→边缘DNAI-B
}
ULCL_Inserted --> ULCL_Removed: SMF触发<br/>UL CL移除<br/>(UE离开边缘区)
ULCL_Removed --> SinglePSA
ULCL_Reconfigured --> ULCL_Removed
SSC Mode 3的核心特点是Make-Before-Break:在新PSA3建立完成之前,旧PSA2不会释放,通过数据转发隧道保证零丢包。
关键步骤(TS 23.502 Section 4.3.5.3):
| 步骤 | 消息 | 关键IE | 说明 |
|---|---|---|---|
| 1 | SMF内部决策 | — | 根据UE位置报告或AF请求确定需要DNAI Change |
| 2 | SMF→PSA3: N4 Est | PDR+FAR+QER | 建立新边缘锚点的N4会话 |
| 3 | SMF→UL CL: N4 Mod | 更新FAR | UL CL增加到PSA3的转发规则,同时保留到PSA2的规则 |
| 4 | SMF→PSA2: N4 Mod | Data Forwarding | 配置PSA2到PSA3的数据转发隧道 |
| 5 | SMF→RAN: N2 SM Info | N3 F-TEID | 如果I-UPF变更,更新RAN的UL隧道终点 |
| 6 | SMF→UE: Mod Command | QoS Rule | 通知UE可能更新的QoS参数 |
| 7 | SMF→PSA2: N4 Release | — | 确认流量迁移完成后释放旧N4会话 |
| 8 | SMF→AF: DNAI Notify | DNAI New | 通知AF应用层执行应用上下文迁移 |
DNAI重定位期间,PSA2和PSA3之间通过N9 Data Forwarding Tunnel传递in-flight数据包:
时间线:
T0: SMF决定DNAI Change
T1: PSA3 N4 Session建立完成
T2: UL CL开始将新流量发送到PSA3
PSA2仍然接收旧流量中的in-flight包
T3: PSA2将缓存的DL包通过Forwarding Tunnel转发到PSA3
T4: SMF确认无流量后释放PSA2的N4 Session
[T0]────[T1]────[T2]────[T3]────[T4]>
│ │ │ │ │
│ 建立PSA3 UL CL 数据 释放PSA2
│ │ 更新 转发 │
▼ ▼ ▼ ▼ ▼
┌─────────────────────────────────────┐
│ PSA2 ════════╗ │
│ ║ Forwarding Tunnel │
│ PSA3 ════════╝ │
│ UL CL ──→ PSA3(新) + PSA2(旧) │
└─────────────────────────────────────┘
TS 23.503 Section 6.1.2定义了AF如何通过PCF影响SMF的流量路由决策,这是MEC场景下最常用的触发方式:
flowchart TD
subgraph "AF/MEP"
A1["AF请求<br/>Npcf_PolicyAuthorization"]
A2["Traffic Descriptor<br/>+ Target DNAI"]
end
subgraph "PCF"
B1["AF请求映射为<br/>PCC Rule"]
B2["trafficSteeringPolId<br/>routeToLocs<br/>offline/online charging"]
B3["SM Policy Decision<br/>下发到SMF"]
end
subgraph "SMF"
C1["解析PCC Rule"]
C2["UPF选择<br/>(DNAI→PSA映射)"]
C3["生成N4 Rules<br/>PDR/FAR/QER/URR"]
end
subgraph "UPF(UL CL)"
D1["执行分流<br/>基于PDR过滤"]
D2["FAR转发到<br/>目标PSA"]
end
A1 --> B1
A2 --> B1
B1 --> B2
B2 --> B3
B3 --> C1
C1 --> C2
C2 --> C3
C3 --> D1
D1 --> D2
根据TS 23.503 Section 6.1.2.14,PCC Rule中与流量导向相关的IE包括:
| IE名称 | 类型 | 说明 |
|---|---|---|
trafficSteeringPolIdDl |
String | 下行流量导向策略标识,引用预定义的UL CL分流模板 |
trafficSteeringPolIdUl |
String | 上行流量导向策略标识 |
routeToLocs |
List | 目标DNAI列表,每个元素含dnai和routeProfId |
routeToLocs[].dnai |
String | 目标数据网络接入标识 |
routeToLocs[].routeProfId |
String | 路由配置文件,包含QoS参数和UPF接口配置 |
upPathChgEvent |
Event | DNAI Change事件订阅请求 |
addRouteToLocs |
List | 增加新的路由目标(不替换已有的) |
delRouteToLocs |
List | 删除指定路由目标 |
UL CL UPF的N4会话中最核心的是Create PDR中的packetDetectionRule:
PDR #1 (边缘流量匹配):
├── PDR ID: 1
├── Precedence: 100 (高优先级)
├── PDI (Packet Detection Information):
│ ├── Source Interface: ACCESS (来自UE/RAN)
│ ├── F-TEID: [RAN分配的N3 TEID]
│ ├── UE IP Address: [UE IP]
│ └── SDF Filter: [边缘应用IP/Port/Protocol]
├── Outer Header Removal: Yes (去除GTP-U头)
├── FAR ID: 1 → 转发到PSA2
└── QER ID: 1 → QoS限速
PDR #2 (默认流量匹配):
├── PDR ID: 2
├── Precedence: 200 (低优先级)
├── PDI:
│ ├── Source Interface: ACCESS
│ ├── F-TEID: [RAN分配的N3 TEID]
│ └── UE IP Address: [UE IP]
├── Outer Header Removal: Yes
└── FAR ID: 2 → 转发到PSA1
SDF Filter(Service Data Flow Filter) 是UL CL分流的核心判据,支持: - IPv4/IPv6 5-tuple(源/目的IP、源/目的端口、协议号) - FQDN匹配(通过DNS解析结果关联) - SNI(Server Name Indication)匹配(TLS握手阶段提取)
FAR #1 (边缘分流):
├── FAR ID: 1
├── Apply Action: FORK (复制) 或 FORWARd
├── Forwarding Parameters:
│ ├── Destination Interface: CORE (N9方向)
│ ├── Network Instance: [边缘DN实例名]
│ ├── Outer Header Creation:
│ │ ├── Outer Header: GTP-U/UDP/IPv4
│ │ ├── TEID: [PSA2分配的N9 TEID]
│ │ └── IP Address: [PSA2 N9接口IP]
│ └── Transport Level Marking: [DSCP值]
└── Duplication Parameters: (可选, 用于LI)
FAR #2 (默认转发):
├── FAR ID: 2
├── Apply Action: FORWARD
├── Forwarding Parameters:
│ ├── Destination Interface: CORE
│ ├── Outer Header Creation:
│ │ ├── TEID: [PSA1分配的N9 TEID]
│ │ └── IP Address: [PSA1 N9接口IP]
│ └── Transport Level Marking: [DSCP值]
graph TD
UE["UE<br/>(IP: 10.1.1.2)"]
RAN["(R)AN<br/>gNB"]
subgraph "UL CL UPF (I-UPF)"
ULCL["UL CL Function<br/>PDR#1: 匹配边缘App → FAR#1<br/>PDR#2: 匹配默认流量 → FAR#2"]
end
subgraph "中心数据中心"
PSA1["PSA1 UPF<br/>(中心锚点)<br/>DNAI: Central"]
CDN["中心DN<br/>(Internet/Org DNS)"]
end
subgraph "边缘站点A"
PSA2["PSA2 UPF<br/>(边缘锚点)<br/>DNAI: Edge-Site-A"]
MEC["MEC Server<br/>(EHE)<br/>低时延应用"]
end
UE -->|"N3 GTP-U"| RAN
RAN -->|"N3 GTP-U"| ULCL
ULCL -->|"PDR#1匹配<br/>N9隧道"| PSA2
ULCL -->|"PDR#2匹配<br/>N9隧道"| PSA1
PSA1 -->|"N6"| CDN
PSA2 -->|"N6"| MEC
PSA1 -.->|"DL: N9→UL CL→N3→UE"| ULCL
PSA2 -.->|"DL: N9→UL CL→N3→UE"| ULCL
style ULCL fill:#bbdefb,stroke:#1565c0
style PSA1 fill:#c8e6c9,stroke:#2e7d32
style PSA2 fill:#fff9c4,stroke:#f57f17
style MEC fill:#ffccbc,stroke:#d84315
分流决策示例:
| UE发起的流量 | 匹配PDR | FAR动作 | 实际路径 |
|---|---|---|---|
| 目的IP=边缘App Server(192.168.100.5):8080/TCP | PDR#1 (Precedence 100) | FAR#1→PSA2 | UE→RAN→UL CL→PSA2→边缘DN |
| 目的IP=公网Web(203.0.113.50):443/TCP | PDR#2 (Precedence 200) | FAR#2→PSA1 | UE→RAN→UL CL→PSA1→中心DN |
| 目的IP=DNS Server(8.8.8.8):53/UDP | PDR#2 (Precedence 200) | FAR#2→PSA1 | UE→RAN→UL CL→PSA1→中心DN |
| 目的IP=边缘DNS(192.168.100.1):53/UDP | PDR#1 (Precedence 100) | FAR#1→PSA2 | UE→RAN→UL CL→PSA2→边缘DN |
N4接口(PFCP)识别UL CL插入:
- 关注PFCP Session Establishment Request中Create PDR的Source Interface = ACCESS且存在多个PDR指向不同FAR
- Outer Header Creation中的TEID/IP变化表明新增了N9隧道
N11接口(SBI: N1N2MessageTransfer)识别:
- HTTP POST /namf-comm/v1/ue-contexts/{supi}/n1-n2-messages
- N2 SM Information中包含新的UPF Information和N3 DL Tunnel Info
- N1 SM Container中为PDU Session Modification Command
N3接口(GTP-U)识别: - 观察GTP-U隧道的TEID变化:RAN发往UL CL的TEID与之前发往PSA1的TEID不同 - 抓包中看到同一UE的流量被分发到不同的N9隧道终点IP
| 故障现象 | 可能原因 | 排查方法 |
|---|---|---|
| 边缘流量仍走中心PSA | PDR过滤器配置错误(IP/Port不匹配) | 检查SMF下发给UL CL的N4 PDR的SDF Filter |
| UL CL插入后UE无法上网 | FAR#2(默认转发)配置缺失或N9隧道未建立 | 检查N4 Session Modification日志,确认FAR完整性 |
| DNAI重定位丢包 | 转发隧道未及时建立或SMF过早释放旧PSA | 分析N4 Session Release时序,确认Make-Before-Break |
| 边缘应用延迟高 | UL CL UPF与PSA2物理距离远,N9隧道绕行 | 检查UPF拓扑部署,确认DNAI到PSA的映射关系 |
| AF收不到DNAI Change通知 | upPathChgEvent未订阅或PCF未配置Notification URL |
检查AF的PolicyAuthorization请求中是否包含事件订阅 |
| ## 八、TS 23.548 Release 18新增特性 |
TS 23.548在Rel-17/18中引入了多项边缘计算增强:
EAS(Edge Application Server)Discovery 是Rel-18新增的关键能力(TS 23.548 Section 6.4)。当UE移动到新的MEC站点时,需要发现该站点上的EAS地址。3GPP定义了两种发现机制:
当DNAI Change发生时,如果新站点有不同的EAS实例,需要触发EAS Rediscovery:
触发条件: SMF检测到DNAI Change
↓
SMF通知UE: 发送EAS Rediscovery指示
(通过PDU Session Modification Command中的
"EAS rediscovery indication" IE)
↓
UE收到指示后:
→ 重新发起DNS查询 → 获取新EAS地址
→ 或等待AF推送新EAS信息
↓
UE连接到新EAS: 建立新TCP/TLS会话
Edge Relocation与DNAI Relocation的区别在于:Edge Relocation不仅涉及UPF锚点迁移,还涉及应用层上下文迁移——即EAS上的应用状态从旧站点迁移到新站点。TS 23.548定义了以下信息流:
| 步骤 | 动作 | 涉及接口 |
|---|---|---|
| 1 | SMF通知AF DNAI即将变更 | Npcf/Nsmf |
| 2 | AF协调EAS上下文迁移 | 应用层(EAS↔EAS) |
| 3 | SMF建立新PSA并插入UL CL | N4 |
| 4 | 确认应用迁移完成 | 应用层 |
| 5 | SMF释放旧PSA | N4 |
| 6 | 通知UE更新EAS地址 | N1 NAS |
场景:某汽车工厂部署5G专网,AGV小车通过5G连接工厂MES系统和边缘AI质检服务器。
网络拓扑: - PSA1(中心UPF):连接工厂总部MES系统,处理ERP/MES流量 - PSA2(边缘UPF):部署在车间MEC平台,连接AI质检服务器(URLLC低时延) - UL CL UPF:部署在工厂5GC机房
分流策略: - AI质检流量(目的IP=192.168.10.0/24,端口5000/TCP)→ PSA2 → 边缘AI服务器 - MES/ERP流量(目的IP=10.0.0.0/8)→ PSA1 → 总部数据中心 - 其他流量 → PSA1 → Internet(如果策略允许)
典型故障案例:AGV小车从车间A移动到车间B,触发DNAI重定位。由于车间B的边缘UPF尚未完成N4 Session建立,导致UL CL分流规则更新延迟,约500ms内AI质检流量丢失。
解决方案:启用SSC Mode 3 + 提前触发(基于UE移动轨迹预测),在UE到达车间B覆盖区边缘时就开始建立PSA3的N4 Session,实现无缝迁移。
Q1: UL CL和L-BO(Local Breakout)有什么区别?
A: UL CL是3GPP定义的标准化分流机制,通过PDR/FAR规则在UPF内部实现,对UE完全透明。L-BO(Local Breakout)是更宽泛的概念,指任何将流量"就近"分流出核心网的方式,可能通过UL CL实现,也可能通过专用DNN或网络切片实现。UL CL是LBO的一种具体技术手段。
Q2: 一个PDU Session可以插入多个UL CL吗?
A: 根据TS 23.501 Section 5.6.7,一个PDU Session可以串联最多两个UL CL UPF,形成最多三个PSA(PSA1+PSA2+PSA3)的拓扑。但实际部署中,一个UL CL已能满足绝大多数MEC场景,双UL CL主要用于超大规模运营商的分级边缘架构(区域边缘+本地边缘)。
Q3: UL CL插入是否需要UE参与?
A: 在大多数情况下不需要。UL CL的插入、修改、移除完全由网络侧(SMF)控制。SMF通过N4接口配置UPF,通过N2接口更新RAN的隧道信息。UE可能收到PDU Session Modification Command,但主要是通知QoS变更,UE无需理解UL CL的概念。唯一的例外是EAS Rediscovery场景,UE需要根据网络指示重新发起DNS查询。
Q4: DNAI Change通知AF后,AF需要做什么?
A: AF收到DNAI Change通知后,可能执行以下操作之一: 1. 触发应用层迁移:将应用上下文从旧EAS迁移到新EAS(Edge Relocation) 2. 更新应用路由:修改应用层的负载均衡配置,将后续请求导向新站点 3. 更新DNS记录:如果AF控制DNS,更新EAS的DNS解析结果 4. 仅记录:对于无状态应用,AF可能仅做审计记录
Q5: UL CL方案中,计费和合法拦截如何处理?
A: TS 23.501 Section 5.6.7明确要求UL CL/BP方案必须支持计费和合法拦截。计费方面:每个PSA独立上报URR(Usage Reporting Rule),SMF合并后发送给CHF。合法拦截方面:LI功能在PSA1(中心锚点)执行,因为它能看到所有经过该PDU Session的流量;如果需要在边缘PSA执行LI,则需要在PSA2上也配置IRI(Intercept Related Information)和CC(Communication Content)规则。
本文由「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 等场景全覆盖。
