<!-- title: 5G边缘应用重定位信令全链拆解 -->
<!-- domain: slicing-mec -->

# 5G边缘应用重定位（EAS Relocation）信令全链拆解

> 聚焦 3GPP TS 23.548（5G 系统边缘计算增强）第 6.3 节，结合 TS 23.502 第 4.3.5 节与 TS 23.501 第 5.13 节，深度解析 UE 移动或 AF 触发场景下，SMF 如何完成 DNAI 变更、PSA UPF 重选/UL CL 插入、DNAI 变更通知，以及 AF 侧应用上下文迁移的完整信令链。

## 一、为什么需要"应用重定位"——与 UL CL 本地分流的本质区别

在前序文章中我们已经拆解过 **UL CL（Uplink Classifier）分支点本地分流**：它在 PDU 会话建立阶段就把 UE 业务锚定到中心 PSA，并插入一个 UL CL 把时延敏感业务分流到本地 L-PSA。那个场景的关键词是**"初始锚定 + 静态分流"**。

而本文聚焦的 **Edge Application Relocation（边缘应用重定位，EAS Relocation）** 解决的是一个动态问题：

> UE 已经在使用某个边缘 EAS，由于**移动**或**应用层决策**，需要把业务从"旧边缘站点"迁到"新边缘站点"，同时**尽量不中断业务**。

这带来了三个 UL CL 本地分流不涉及的难题：

1. **用户面路径迁移**：PSA UPF 要从旧的 L-PSA 换到新的 L-PSA（PSA relocation），或者重新插入/调整 UL CL；
2. **应用上下文迁移**：AF/EAS 要把会话状态（session context）从旧 EAS 搬到新 EAS；
3. **5GC 与应用层协同**：SMF 必须**先通知 AF**（DNAI 变更通知），让 AF 有时间迁移应用上下文，**然后**再切换用户面——这就是规范里"early notification + AF-ACK"机制存在的根本原因。

可以说，UL CL 分流是"一次性铺好路"，而 EAS Relocation 是"边跑边换道"。

## 二、核心概念与网元角色

下表梳理本文反复出现的关键术语与网元角色：

| 概念/网元 | 全称与含义 | 在重定位中的角色 |
|-----------|-----------|------------------|
| **DNAI** | Data Network Access Identifier，标识接入某个 DN（边缘站点）的入口 | 重定位的本质就是 **DNAI 变更**（TS 23.501 5.6.7） |
| **PSA UPF** | PDU Session Anchor UPF，会话锚点 | 中心 PSA 或本地 L-PSA；重定位会改变锚点 |
| **L-PSA** | Local PSA，靠近边缘站点的本地锚点 | 新目标锚点，承载新 EAS 业务 |
| **UL CL / BP** | Uplink Classifier / Branching Point，上行分类器/分支点 | 用于在不改变锚点的情况下把业务"拐"到本地 |
| **SSC Mode 3** | Service & Session Continuity Mode 3，允许网络改变锚点且不中断业务 | 重定位无中断依赖 SSC Mode 3（make-before-break） |
| **EAS** | Edge Application Server，边缘应用服务器 | 应用上下文的实际承载者，需要被迁移 |
| **AF** | Application Function，应用功能 | 接收 DNAI 通知、触发/执行应用上下文迁移 |
| **EASDF** | Edge Application Server Discovery Function | DNS 解析发现 EAS，可在迁移后触发重新发现 |
| **NEF** | Network Exposure Function | 当 AF 不可信（第三方）时，NEF 居中做能力开放 |

```mermaid
flowchart TD
    A[边缘重定位触发源] --> B1[AF 主动触发<br/>TS 23.548 6.3.7<br/>Nnef_TrafficInfluence 指向 UE]
    A --> B2[SMF 本地策略触发<br/>UE 移动 / TAC 变更<br/>推断需切换 DNAI]
    A --> B3[EASDF DNS 触发<br/>TS 23.502 4.3.5.1<br/>DNS Response 含 EAS IP]
    B1 --> C[SMF 决策 DNAI 变更]
    B2 --> C
    B3 --> C
    C --> D1{SSC 模式/方案选择}
    D1 -->|换锚点| E1[PSA Relocation<br/>新 L-PSA 取代旧 PSA]
    D1 -->|不换锚点| E2[UL CL/BP 插入或调整<br/>业务分流到新 L-PSA]
    E1 --> F[DNAI 变更通知 AF]
    E2 --> F
    F --> G[AF 迁移应用上下文 EAS1→EAS2]
    G --> H[AF-ACK + 用户面切换]
    style C fill:#fff3cd
    style F fill:#d1ecf1
```

## 三、EAS 重定位的两种模式：IP 地址保留 vs 不保留

TS 23.548 6.3 把 EAS 重定位划分为两种模式，决定了 UE 是否需要重新发现 EAS、是否需要重连：

| 维度 | **保留 IP 地址**（With IP preservation） | **不保留 IP 地址**（Without IP preservation） |
|------|------------------------------------------|----------------------------------------------|
| UE 侧 IP | UE IP 保持不变（如 SSC Mode 3 + 地址保留） | 可能变化，或通过网络侧 EAS IP 替换保持 UE 无感 |
| EAS 地址 | 新 EAS 通常需匹配 UE 已知地址 | 可使用 EAS IP Replacement 或触发 UE EAS 重新发现 |
| 实现复杂度 | 高，要求 L-PSA 间 IP 连续性 | 较低，依赖 UL CL 做 IP 替换或 DNS 重新发现 |
| 典型场景 | 长会话类业务（云游戏、远程协作） | 短连接、可容忍重连的业务 |
| 涉及流程 | PSA Relocation + 地址保留 + SSC Mode 3 | UL CL 插入 + EAS IP 替换 / EASDF 重新发现 |

理解这个二分法的钥匙在于：**重定位不是单纯的网络侧动作，必须和应用层"对账"**——告诉 UE 和 EAS"我们换了地方"。

## 四、完整信令时序图：SMF 主导的 DNAI 变更 + 应用迁移

下图是一个**SMF 触发（UE 移动）**场景下，采用 **PSA Relocation + SSC Mode 3（make-before-break）+ early notification** 的完整信令流。这也是抓包时最典型、信息最完整的一条链：

```mermaid
sequenceDiagram
    autonumber
    participant UE
    participant RAN as (R)AN
    participant AMF
    participant SMF
    participant UPF1 as 旧 PSA (中心)
    participant UPF2 as 新 L-PSA
    participant UCL as UL CL/BP
    participant PCF
    participant NEF
    participant AF as AF/EAS1→EAS2

    Note over UE,UPF1: 初始: UE 锚定在中心 PSA(UPF1), 经 UL CL 分流到 EAS1
    UE->>RAN: 移动 / 进入新跟踪区
    RAN->>AMF: N2 Path Switch Request (新用户位置)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext (UE 位置变更)
    Note over SMF: ① SMF 据策略判定需变更 DNAI (迁到 L-PSA UPF2)

    SMF->>AF: ② Early DNAI Change Notification (via NEF)<br/>Nsmf/Nnef_EventExposure_Notify<br/>含: 新DNAI, PDU Session ID, AF-ACK requested
    Note over AF: ③ AF 启动应用上下文迁移 EAS1→EAS2
    AF-->>SMF: ④ AF-ACK (Nnef... ack, EAS2 就绪)
    Note over SMF: ⑤ 收到 ACK, 执行 make-before-break

    SMF->>UPF2: ⑥ N4 Session Establishment (PFCP)<br/>PDR/FAR: 检测+转发到 EAS2/新隧
    UPF2-->>SMF: N4 Establishment Response (新 N9 TEID)

    SMF->>UCL: ⑦ N4 Session Modification<br/>更新 FAR: 上行业务拐向 UPF2
    SMF->>AMF: ⑧ Namf_Communication_N1N2MessageTransfer<br/>N2 SM info (新N3 UL TEID) + N1 SM Container
    AMF->>RAN: ⑨ N2 PDU Session Resource Modification
    RAN->>UE: ⑩ RRC Reconfiguration (切换上行隧道)
    UE-->>RAN: RRC Reconfiguration Complete
    RAN-->>AMF: N2 Response (新 N3 DL TEID)
    AMF-->>SMF: Nsmf_PDUSession_UpdateSMContext (N2 SM resp, DL TEID)

    SMF->>UPF2: ⑪ N4 Modification (写入 N3 DL TEID)
    SMF->>AF: ⑫ Late DNAI Change Notification (迁移完成)
    SMF->>UPF1: ⑬ N4 Session Release (释放旧锚点/N9)
    Note over UE,UPF2: 业务现经 新L-PSA(UPF2) 访问 EAS2
```

## 五、关键信令消息与 IE 逐步解析

下表对时序图中各步骤的关键 Information Element（信息元素）做拆解，是抓包对照时的核心查检表：

| 步骤 | 消息/服务操作 | 关键 IE | 说明 |
|------|--------------|---------|------|
| ① | SMF 内部决策 | DNAI(old)→DNAI(new)、UPF 候选列表 | 由 UE 位置 + DNAI↔UPF 映射表 + 策略决定 |
| ② | `Nnef/Nsmf_EventExposure_Notify`（Early） | `DNAI`、`PduSessionId`、`AfAckRequested`、`NotificationType=EARLY`、` UEAddr` | **Early** 通知：重定位**之前**发，等 AF 准备 |
| ④ | AF-ACK | `Ack`、`TrafficRoutingInfo`（可选） | AF 确认 EAS2 已就绪，SMF 才往下走 |
| ⑥ | `N4 Session Establishment`（PFCP） | PDR（检测规则）、FAR（转发动作：新 EAS/新 N9）、`F-TEID` | 在新 L-PSA 建立检测+转发面 |
| ⑦ | `N4 Session Modification`（UL CL） | FAR 更新：上行匹配业务改转发到 UPF2 | UL CL 方案下"换道"的关键 |
| ⑧ | `Namf_Communication_N1N2MessageTransfer` | N2 SM Info（新 N3 UL `F-TEID`）、N1 SM Container（`PDU Session Modification Command`） | 给 AN 新隧道 + 给 UE 修改命令 |
| ⑫ | `EventExposure_Notify`（Late） | `NotificationType=LATE`、新 `DNAI` | 告知 AF：用户面已切到新站点 |
| ⑬ | `N4 Session Release` | 释放的 `SEID`、`F-TEID` | 释放旧 PSA，回收 N3/N9 资源 |

其中最容易被工程师忽略、却最关键的是 **步骤②的 `NotificationType` 与 `AfAckRequested`**——它直接决定了用户面切换的时序，是 EAS Relocation 区别于普通会话修改的灵魂。

## 六、Early / Late 通知与 AF-ACK：为什么这样设计

DNAI 变更通知有**早通知（Early）**和**晚通知（Late）**两个时间点，并支持 AF-ACK。这套机制的设计意图可以从下表理解：

| 通知类型 | 触发时刻 | AF 动作 | 设计意图 |
|----------|----------|---------|----------|
| **Early** | 用户面切换**之前** | 迁移应用上下文、预置 EAS2，回 ACK | 让应用层"先准备好再切路"，避免切换瞬间丢包/断会话 |
| **Late** | 用户面切换**之后** | 完成切换收尾（如通知 UE 新 EAS IP、回收 EAS1） | 告知应用层迁移落地，做最终对账 |
| **AF-ACK** | Early 之后、切换之前 | 显式确认就绪 | 给 SMF 一个"安全闸"——没收到 ACK 就不切，保证业务连续性 |

这一设计的核心矛盾是：**网络层切得快，但应用层状态搬得慢**。如果 SMF 直接切用户面，新 EAS 还没有会话上下文，业务必然中断。Early notification + AF-ACK 本质上是**在用户面切换前插入一个应用层的同步点**，用一次 ACK 把网络和应用"对齐"后再切。这正是 SSC Mode 3 make-before-break 在边缘场景下的工程化落地。

## 七、N4（PFCP）侧细节：检测与转发规则的编排

EAS Relocation 在用户面归根到底是 **PDR/FAR 的重编排**：

- **旧 L-PSA（UPF1）**：其 PDR/FAR 负责把目标业务送到 EAS1；迁移后这些规则随 `N4 Session Release` 一并删除。
- **新 L-PSA（UPF2）**：通过 `N4 Session Establishment` 下发新 PDR（如按 SDF 模板/五元组检测到 EAS 业务）+ 新 FAR（转发到 EAS2 与新 N9/N3 隧道）。
- **UL CL/BP**（若采用不换锚点方案）：通过 `N4 Session Modification` 把匹配业务的 FAR 转发目标从 EAS1/UPF1 改指 EAS2/UPF2，实现"换道不换锚点"。

对于**不保留 IP 地址**模式，规范还引入 **EAS IP Replacement**：UL CL/L-PSA 把 UE 上行报文的目的 IP（旧 EAS IP）替换为新 EAS IP，使 UE 侧无需重连或重新 DNS 发现即可无感切换——这是边缘计算相对于普通 PDU 会话修改最独特的增强点之一。

## 八、抓包识别：如何认出这条流程

在 Wireshark/tshark 中，可按以下过滤器定位（以 NGAP/5G-NAS/PFCP/SBI 视角）：

```text
# 1) SBI 侧 DNAI 变更通知（HTTP/2 POST 到 NEF/SMF 的 eventexposure notify）
http2.header.value contains "event-exposure" and http2.header.value contains "notify"

# 2) AF-ACK（PUT/PATCH traffic-influence）
http2.headers contains "traffic-influence"

# 3) N4 侧新 L-PSA 建立 + 旧 PSA 释放
pfcp.msg_type == 50  and  (pfcp || pfcp.seid)   # 50 = Session Establishment Request

# 4) NGAP 会话修改（用户面路径切换）
ngap.procedureCode == 48   # PDUSessionResourceModify
```

识别要点：

- **N1 SM Container** 里出现 `PDU Session Modification Command`，且伴随**新的 N3 UL F-TEID**，而会话 ID 不变——典型 PSA relocation/UL CL 调整；
- **SBI** 上若看到 `Nnef` 的 `traffic-influence` 与 `event-exposure notify` 成对出现，基本可确认是 AF 影响路由 + DNAI 通知链；
- **N4** 上同时出现一次 `Session Establishment`（新 L-PSA）与一次 `Session Release`（旧 PSA），且二者时间接近，是 PSA Relocation 的强特征。

## 九、常见故障点与排错思路

| 故障现象 | 可能根因 | 排错方向 |
|----------|----------|----------|
| 切换瞬间业务卡顿/断流 | AF 未回 ACK 或 Early 通知丢失，SMF 强切 | 检查 `AfAckRequested` 与 ACK 是否到达；NEF 转发是否成功 |
| 切换后业务仍走旧 EAS | UL CL 的 FAR 未更新，或新 L-PSA PDR 漏配 | 核对 N4 Modification 中 FAR 转发目标、PDR 检测模板 |
| UE 无法访问新 EAS | EAS IP Replacement 规则错误，或 UE 需 EAS 重新发现 | 确认模式（保留/不保留 IP），检查 UL CL 替换规则或触发 DNS |
| 重定位不发生 | SMF 策略未配置 DNAI↔UPF 映射，或 AF 影响未下发到 SMF | 核查 SMF UPF 选择策略、PCF 是否下发 RoutingInfo |
| 旧 PSA 资源未释放 | Late 通知/路径切换未完成导致 SMF 不释放 | 检查 N2 Response、N4 Modification 是否完成 |
## 十一、EAS 重定位状态机

下图从 **AF/应用层视角**刻画 EAS 重定位的状态流转，便于理解业务连续性保障：

```mermaid
stateDiagram-v2
    [*] --> ServedByEAS1: UE 锚定旧边缘
    ServedByEAS1 --> RelocationPending: 收到 Early DNAI 通知
    RelocationPending --> ContextMigrating: AF 开始迁移上下文 EAS1→EAS2
    ContextMigrating --> RelocationReady: 上下文迁移完成
    RelocationReady --> SendingAck: AF 回 AF-ACK
    SendingAck --> PathSwitching: SMF 切换用户面(make-before-break)
    PathSwitching --> ServedByEAS2: 收到 Late 通知, 切换落地
    ServedByEAS2 --> [*]: 回收 EAS1
    note right of RelocationPending
        此状态由 AfAckRequested 触发
        SMF 在此暂停, 等待应用层就绪
    end note
```

## 十二、设计哲学小结

EAS Relocation 的精妙之处，在于它**把"网络层路径切换"和"应用层状态迁移"通过 DNAI 变更通知 + AF-ACK 解耦又同步**：

- 网络侧用 **SSC Mode 3 的 make-before-break** 保证隧道不中断；
- 应用侧用 **Early/Late notification + ACK** 保证会话上下文先就位；
- 用户面用 **PDR/FAR 重编排 + 可选 EAS IP Replacement** 保证业务无感换道。

三者协同，才让 5G 边缘计算真正具备"跟随 UE 移动、业务不中断"的能力——这也是它远超 4G 本地分流（LBO/SIPTO）的根本所在。

## 常见问题

**Q1: EAS Relocation 和普通的 PDU Session Modification 有什么区别？**
A: 普通 Modification 只改 QoS/规则，不换锚点；EAS Relocation 必然涉及 DNAI 变更与 PSA/UL CL 重编排，并强制要求 AF 侧应用上下文协同（DNAI 通知）。本质区别在于"是否换边缘站点 + 是否需应用层同步"。

**Q2: 什么情况下用 PSA Relocation，什么情况下用 UL CL？**
A: 若希望锚点就近、降低端到端时延且支持 SSC Mode 3，用 PSA Relocation（换锚点）；若希望锚点不动、实现简单、便于地址连续，用 UL CL（插分支点）。前者更强、更复杂，后者更轻量。

**Q3: 为什么必须有 AF-ACK，不能 SMF 自己切？**
A: 因为应用层会话上下文迁移慢于网络层隧道切换。若 SMF 直接切，新 EAS 没有上下文会立刻断业务。AF-ACK 是给网络层一个"应用已准备好"的安全闸，保证业务连续性。

**Q4: EAS IP Replacement 和 EAS 重新发现（Re-discovery）有什么区别？**
A: Replacement 由网络侧（UL CL/L-PSA）透明替换报文目的 IP，UE 无感、不重连；Re-discovery 则要求 UE 重新走 DNS（经 EASDF）获取新 EAS IP，会有短暂重连。前者体验更好但 UPF 要求高。

**Q5: DNAI 变更通知一定要经 NEF 吗？**
A: 不一定。若 AF 是可信的运营商内部 AF，可直接与 SMF/PCF 交互（不经 NEF）；若 AF 是第三方不可信 AF，则必须经 NEF 做鉴权与能力开放（`Nnef_TrafficInfluence`）。

## 参考来源

1. [3GPP TS 23.548 V18.9.0 — 5G System Enhancements for Edge Computing; Stage 2](https://www.etsi.org/deliver/etsi_ts/123500_123599/123548/18.09.00_60/ts_123548v180900p.pdf) — 第 6.3 节 Edge Relocation、6.3.7 AF 触发、6.7.3 EAS Re-discovery and Edge Relocation
2. [3GPP TS 23.502 — Procedures for the 5G System](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/) — 第 4.3.5 节 Specific to Edge Computing（PSA 变更、DNAI 变更通知）
3. [3GPP TS 23.501 — System architecture for the 5G System](https://www.etsi.org/deliver/etsi_ts/123500_123599/123501/) — 第 5.13 节 Edge Computing、第 5.6.7 节 DNAI、第 5.6.4 节 SSC 模式
4. [3GPP TS 29.508 — Session Management Event Exposure Service](https://www.etsi.org/deliver/etsi_ts/129500_129599/129508/) — Nsmf_EventExposure（DNAI 变更通知的服务定义）
5. [TS 23.548 Section 6.3 — Edge Relocation | iTecSpec](https://itecspec.com/3gpp/23.548/s/6.3) — 第 6.3 节流程结构与子节索引
6. [ShareTechnote — 5G Core SMF](https://www.sharetechnote.com/html/5G/5G_Core_SMF.html) — SMF 在边缘场景下的会话管理与 UPF 选择背景

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