<!-- title: 5G UL CL上行分流器插入与DNAI重定位信令全链拆解 -->
<!-- domain: slicing-mec -->

# 5G UL CL上行分流器插入与DNAI重定位信令全链拆解

## 一、背景与核心概念

在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定义 |

### 1.1 UL CL与BP的本质区别

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实现的复杂度。

### 1.2 DNAI——数据网络接入标识

**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操作）

## 二、UL CL插入完整信令时序图

以下流程基于**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插入的完整过程：

```mermaid
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
```

### 2.1 信令阶段详解

**阶段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），核心是下发三类规则：

- **PDR（Packet Detection Rule）**：定义流量检测模板，UL CL的PDR中包含`sourceInterface=ACCESS`和UL方向流量过滤器
- **FAR（Forwarding Action Rule）**：定义匹配PDR后执行的动作，UL CL的FAR将匹配流量通过N9隧道转发到PSA2，不匹配的流量继续转发到PSA1
- **QER（QoS Enforcement Rule）**：执行QoS限速和标记

```mermaid
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
```

## 三、DNAI重定位与SSC Mode 3的联动

当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**密切相关：

```text
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
```

### 3.1 SSC Mode 3下的DNAI重定位信令

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应用层执行应用上下文迁移 |

### 3.2 数据转发隧道机制

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(旧)      │
  └─────────────────────────────────────┘
```

## 四、AF影响流量路由的PCC策略链

TS 23.503 Section 6.1.2定义了AF如何通过PCF影响SMF的流量路由决策，这是MEC场景下最常用的触发方式：

```mermaid
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
```

### 4.1 PCC Rule中的关键流量导向IE

根据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 | 删除指定路由目标 |

## 五、N4接口PFCP规则详解

### 5.1 UL CL UPF的PDR配置

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握手阶段提取）

### 5.2 FAR（转发动作规则）详解

```
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值]
```

## 六、完整数据面拓扑与分流路径

```mermaid
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 |

## 七、抓包识别与故障排查

### 7.1 抓包关键识别点

**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

### 7.2 常见故障点

| 故障现象 | 可能原因 | 排查方法 |
|---------|---------|---------|
| 边缘流量仍走中心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中引入了多项边缘计算增强：

### 8.1 EAS Discovery增强

**EAS（Edge Application Server）Discovery** 是Rel-18新增的关键能力（TS 23.548 Section 6.4）。当UE移动到新的MEC站点时，需要发现该站点上的EAS地址。3GPP定义了两种发现机制：

1. **DNS-based EAS Discovery**：UE发送DNS查询，DNS Server（可能是本地DNS Resolver）根据UE位置/DNAI返回最优EAS IP
2. **AF-based EAS Discovery**：AF直接向UE推送EAS信息（通过PCF→SMF→AMF→UE路径）

### 8.2 EAS Rediscovery Procedure

当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会话
```

### 8.3 Edge Relocation（TS 23.548 Section 6.3）

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+智慧工厂UL CL分流

**场景**：某汽车工厂部署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）规则。

## 参考来源

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.6.7 (UL CL/BP Architecture), Section 5.13 (Edge Computing Framework)
2. [3GPP TS 23.502 V18.9.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.09.00_60/ts_123502v180900p.pdf) — Section 4.3.5 (PDU Session Modification), Section 4.3.5.3 (SSC Mode 3 UPF Relocation)
3. [3GPP TS 23.548 V18.10.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123548/18.10.00_60/ts_123548v181000p.pdf) — Section 6 (Edge Computing Enablers), Section 6.3 (Edge Relocation), Section 6.4 (EAS Discovery)
4. [3GPP TS 23.503 V18.8.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123503/18.08.00_60/ts_123503v180800p.pdf) — Section 6.1.2 (AF Influence on Traffic Routing PCC Rules)
5. [3GPP TS 29.244 V18.6.0](https://www.etsi.org/deliver/etsi_ts/129200_129299/129244/18.06.00_60/ts_129244v180600p.pdf) — Section 7.5 (PFCP PDR/FAR/QER for UL CL/BP)
6. [free5GC ULCL Traffic Steering Guide](https://deepwiki.com/free5gc/free5gc-compose/8.2-ulcl-traffic-steering) — 开源5GC中UL CL配置与实践
7. [3GPP Edge Computing Portal](https://www.3gpp.org/technologies/edge-computing) — 3GPP边缘计算标准化总览

---

> 本文由「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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)