<!-- title: 5G UL CL本地分流信令流全链拆解 -->
<!-- domain: slicing-mec -->

# 5G UL CL上行分类器MEC本地分流信令流全链拆解

## 一、UL CL机制定位与设计动机

在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功能后，它会：

- **上行方向**：根据SDF Filter（业务流过滤器）检测上行数据包，将匹配本地DN目的地址的流量转发到Local PSA（PDU Session Anchor 2），其余流量继续转发到Central PSA（PDU Session Anchor 1）
- **下行方向**：将来自PSA1和PSA2的下行数据流合并后统一通过N3隧道发送给(R)AN

### UL CL与Branching Point（BP）的区别

这是协议开发工程师最常混淆的概念。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在用户面完成。这极大地简化了终端侧实现复杂度。

## 二、UL CL端到端信令时序图

以下信令流基于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）：

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

## 三、UL CL插入触发条件分析

SMF在以下任何一种条件下触发UL CL的插入。3GPP在TS 23.502 Section 4.3.5和Section 4.3.6中定义了三种主要触发路径：

```mermaid
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的流量路由到本地边缘节点时：

1. AF向PCF（直接或通过NEF）发送**Npcf_PolicyAuthorization_Create**请求
2. 请求中携带的关键参数：
   - **DNAI（Data Network Access Identifier）**：标识目标边缘计算节点的位置
   - **Traffic Steering Profile**：定义流量路由策略
   - **N6 Traffic Routing Information**：N6接口的路由信息
3. PCF将路由策略通过**Npcf_SMPolicyControl_UpdateNotify**下发给SMF
4. SMF根据DNAI选择Local PSA并插入UL CL

**触发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。

## 四、PFCP信令深度解析（TS 29.244）

UL CL机制的核心承载协议是**PFCP（Packet Forwarding Control Protocol）**，定义在TS 29.244中。SMF通过PFCP在UPF上创建四类核心规则：PDR、FAR、QER、URR。

### 4.1 阶段3：PSA-2的PFCP Session Establishment

SMF向Local PSA-2发起PFCP Session Establishment：

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

### 4.2 阶段4：配置UL CL UPF（核心步骤）

这是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
```

### 4.3 PFCP IE嵌套结构图

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

## 五、数据面分流工作机制

### 5.1 上行分流流程

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

### 5.2 下行合并流程

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

## 六、UL CL插入的三种信令路径

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影响路由策略 | 通常不需要 |

### 场景对比

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

## 七、DNAI变更与边缘重定位（TS 23.548 §6.3）

当UE在移动过程中跨越不同的DNAI（Data Network Access Identifier）服务区域时，需要执行**Edge Relocation**（边缘重定位）流程。这在TS 23.548 Section 6.3中有详细定义。

### DNAI变更触发的UL CL重定位流程

1. **SMF检测DNAI变更**：SMF从(R)AN上报的N2消息或AMF转发的事件通知中获知UE的新位置，判断是否需要更换Local PSA
2. **选择新的PSA-2'**：基于新DNAI选择新的边缘UPF
3. **建立新N4会话**：与新PSA-2'建立PFCP Session
4. **更新UL CL规则**：修改UL CL UPF上的FAR，将本地业务流量的N9隧道从旧PSA-2切换到新PSA-2'
5. **删除旧PSA-2的N4会话**：释放旧边缘UPF资源
6. **通知AF（可选）**：通过PCF/NEF向AF发送**Nsmf_EventNotification_Notify**，携带新的DNAI信息，AF可据此将应用实例迁移到新的边缘节点

### DNAI通知机制

```
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通知机制实现了**网络与应用的联动**——当网络侧决定将流量切换到新的边缘节点时，应用侧也能同步迁移服务实例，确保业务连续性。

## 八、抓包识别与排错实战

### 8.1 抓包识别UL CL流程

| 步骤 | 接口 | 协议 | 过滤条件 | 关键字段 |
|------|------|------|---------|---------|
| 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
```

### 8.2 常见故障与排错

| 故障现象 | 可能原因 | 排查方法 |
|---------|---------|---------|
| 本地业务流量未分流到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的约束。

## 参考来源

1. [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.5 (SSC modes), Section 4.3.6 (AF influence on traffic routing), Section 4.23.9.1 (Addition of PDU Session Anchor and UL CL)
2. [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 (UPF functionality: UL CL and Branching Point)
3. [3GPP TS 29.244 V18.x.0](https://www.etsi.org/deliver/etsi_ts/129200_129299/129244/16.04.00_60/ts_129244v160400p.pdf) — PFCP协议定义，PDR/FAR/QER/URR IE结构
4. [3GPP TS 23.548 V18.9.0](https://cdn.standards.iteh.ai/samples/74551/9f54ed2a86af455c96a7cb048d488e0e/ETSI-TS-123-548-V18-9-0-2025-04-.pdf) — Section 6.3 (Edge Relocation), DNAI变更流程
5. [5G MEC UPF选择及本地分流技术分析](https://qikan.cqvip.com/Qikan/Article/Detail?id=7100857825) — UL CL/IPv6多归属/LADN分流策略对比

---
> 本文由「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)