当一部开着云游戏的手机从城东基站一路移动到城西边缘机房附近，正在为它渲染画面的边缘应用服务器（EAS）必须从"城东EAS"无缝切换到"城西EAS"，否则延迟瞬间拉爆、画面卡死。这套"换服务器却不换体验"的能力，正是3GPP TS 23.548《5G系统边缘计算增强》要解决的核心难题——边缘应用重定位（Edge Application Relocation）。
本文聚焦 TS 23.548 clause 6.2.2.3、6.3.2、6.3.3 三条重定位信令路线，逐条拆解从触发、PSA锚点重选、EAS重发现到R18新增的"EAS IP透明替换"全链路，并给出抓包识别要点与排错思路。
边缘计算（MEC）的核心矛盾在于：应用部署得越靠边缘、越靠近无线侧，时延越低；但越靠近边缘，移动性导致的"换锚点"就越频繁。
5G系统从R15起就支持边缘计算（通过UL CL/BP本地分流），但真正把"EAS动态发现与重定位"做成体系化机制是从R17开始的（TS 23.548首版）。到R18，3GPP又补上了"EAS IP Replacement"这条让UE完全无感知的透明重定位路线。
要理解重定位信令，必须先掌握下面四个支柱概念：
| 概念 | 定义 | 所属规范 |
|---|---|---|
| EAS（Edge Application Server） | 部署在边缘的应用服务器实例，每个区域可能部署多个实例 | TS 23.501 5.33 |
| DNAI（Data Network Access Identifier） | 标识"接入到某个数据网络的入口"，等价于"接入哪个边缘站点/DN" | TS 23.501 5.6.7 |
| EASDF（EAS Discovery Function） | 处理UE的DNS查询，按UE当前位置解析出最近的EAS IP | TS 23.501 5.32.2 / TS 23.548 6.2 |
| PSA（PDU Session Anchor） | PDU会话的UPF锚点，决定流量从哪个DN出口到EAS | TS 23.501 4.4.2 |
一句话概括：DNAI决定流量出口，PSA是流量出口的物理实现，EAS是出口那头的服务器，EASDF负责告诉UE"你该连哪台EAS"。 重定位的本质，就是这四者随UE移动而协同重构。
TS 23.548 clause 6.3 把边缘重定位（Edge Relocation）拆成三种机制，它们对"UE是否感知""是否更换IP地址""是否更换PDU会话"给出了不同的权衡：
这三者并非互斥，运营商可按业务对中断敏感度来选型。下文逐条拆解。
这是最完整、最具代表性的重定位流程，由 SMF 在用户面路径管理过程中触发。规范原文明确指出：当需要变更 SSC 模式 2/3 的 PDU Session 锚点时，"SMF触发 TS 23.502 clause 4.3.5.1、4.3.5.2、4.3.5.3 中定义的会话连续性、业务连续性与用户面路径管理流程"，并在此过程中要求UE重新发现EAS。
sequenceDiagram
participant UE
participant RAN as (R)AN
participant AMF
participant SMF
participant EASDF
participant PSA1 as PSA1(旧边缘锚点)
participant PSA2 as PSA2(新边缘锚点)
participant EAS1 as 旧EAS(IP=O)
participant EAS2 as 新EAS(IP=N)
Note over UE,SMF: 阶段0: 触发DNAI变更
SMF->>SMF: 检测UE移出旧DNAI/AF经NEF通知/负载变化
Note over SMF,PSA2: 阶段1: 用户面路径管理(SSC3,TS 23.502 4.3.5.x)
SMF->>PSA2: N4 Session Establishment(插入新PSA+UL CL)
SMF->>PSA1: N4 Session Modification(准备拆除)
SMF->>AMF: Namf_Comm_N1N2MessageTransfer(切换指示)
AMF->>RAN: N2 PDU Session Resource Modify
RAN->>UE: RRC Reconfiguration + NAS
Note over UE,EASDF: 阶段2: EAS重发现(TS 23.548 6.2.2.3)
SMF->>UE: Router Adv(新IPv6前缀)/ EAS重发现指示
UE->>EASDF: DNS Query(FQDN,经PSA2路径)
EASDF->>SMF: 上报EAS部署信息(按订阅)
EASDF->>UE: DNS Response=新EAS2 IP(N)
UE->>EAS2: 建立新应用会话(IP=N)
Note over SMF,PSA1: 阶段3: 旧路径释放(make-after-break)
SMF->>PSA1: N4 Session Release
PSA1-->>EAS1: 应用会话拆除
阶段1：锚点重选（用户面路径管理） SMF一旦判定DNAI需要变更，即按 TS 23.502 4.3.5.x 启动 PSA 重选。对于 SSC 模式 3，采用"先建后断（make-before-break）"：先建立到 PSA2 的新用户面路径（含 UL CL 分流点），再拆除 PSA1。关键动作是 N4 Session Establishment 消息，其中携带：
Network Instance / DNAI：新边缘站点的数据网络入口；F-TEID：新 PSA2 的 GTP-U 隧道端点；UL CL Insertion Flag：是否插入上行分类器，用于把匹配新DNAI的流量导向PSA2；Traffic Detection Rule：基于FQDN/IP五元组检测是否命中边缘应用流量。阶段2：EAS重发现指示（核心机制） 这是 6.2.2.3 的灵魂。SMF 通过 NAS 信令（对IPv6场景封装在 Router Advertisement 的 NDP Option，或经 PCO/Ethernet类型PDU会话）向UE下发： - 新的 IPv6 前缀（因为SSC3换了锚点，UE拿到新IP）； - EAS Rediscovery 触发指示：要求UE应用层重新发起DNS查询。
UE收到指示后，对同一FQDN再次发起 DNS Query，但这次查询经新PSA2路径到达 EASDF。EASDF此时已由SMF更新了"UE当前位置→最优EAS"的解析规则，于是返回距离UE当前位置更近的新EAS IP。应用层随后与新EAS建立会话。
设计意图：把"换服务器"这件事标准化为"换IP+重新DNS"，复用了成熟的DNS与SSC机制，避免为边缘场景再造一套应用层控制协议。代价是UE必须支持应用层重连，存在短暂中断。
阶段3：旧路径释放 在新会话建立、应用层完成状态迁移后，SMF才释放 PSA1（N4 Session Release）。这就是"make-after-break"——先确保新链路可用再断旧链路。
路线一的痛点是"UE必须重连、必然有中断、依赖UE应用层配合"。R18的 EAS IP Replacement（6.3.3）给出了一个优雅得多、几乎是"魔法"的方案：UE从头到尾都不知道服务器换了。
规范原文（6.3.3）指出："EAS IP替换使能本地PSA UPF在上行数据中，把目的IP和端口号从旧Target EAS地址替换为新Target EAS地址；并在下行数据中把源IP和端口号从新Target EAS地址替换回旧Target EAS地址。"
也就是说，UE始终只认一个"旧EAS IP（O）"，但本地PSA在数据面默默做两件事： - 上行：把UE发往IP=O的包，目的地址改写成 IP=N（新EAS），转发给新EAS； - 下行：把新EAS（IP=N）回给UE的包，源地址改写回 IP=O，再发给UE。
对UE而言，它"看到"的一直是与IP=O通信，链路从未中断。
sequenceDiagram
participant AF as AF/应用功能
participant NEF
participant SMF
participant LPSA as 本地PSA UPF
participant UE
participant EASold as 旧EAS(IP=O)
participant EASnew as 新EAS(IP=N)
Note over AF,LPSA: 阶段1: 使能EAS IP替换(6.3.3.1.1)
AF->>NEF: 请求使能EAS IP替换(按EAS部署)
NEF->>SMF: 触发EAS IP Replacement使能
SMF->>LPSA: N4下发EAS IP替换规则(FQDN,端口)
Note over SMF,LPSA: 阶段2: DNAI变更触发更新(6.3.3.1.2)
SMF->>SMF: 检测DNAI变更(UE移动/负载)
SMF->>LPSA: N4 Update: 旧EAS IP(O)↔新EAS IP(N)
Note over UE,EASnew: 阶段3: 透明双向替换
UE->>LPSA: UL: 目的IP=O(UE仍用旧地址)
LPSA->>LPSA: 目的IP: O→N 改写
LPSA->>EASnew: UL转发至新EAS(N)
EASnew->>LPSA: DL: 源IP=N
LPSA->>LPSA: 源IP: N→O 还原
LPSA->>UE: DL: 源IP=O(UE无感知)
本地PSA要完成改写，必须由SMF下发完整的替换规则。其内部结构如下（规范化为类图，便于协议开发同学对照实现）：
classDiagram
class EAS_IP_Replacement_Rule {
+FQDN 目标应用域名
+Old_Target_EAS_IP 旧EAS IPv4/IPv6
+New_Target_EAS_IP 新EAS IPv4/IPv6
+Old_Port 旧端口号
+New_Port 新端口号
+DNAI 数据网络接入标识
+S_NSSAI 切片标识
+DNN 数据网络名
+Apply_Direction UL|DL|双向
}
class EASRediscovery_Indication {
+EASRediscoveryFlag 重发现标志
+New_IPv6_Prefix 新前缀
+TriggerReason 触发原因
}
class N4_Session_Modify {
+EAS_IP_Replacement_Rule
+UL_CL_Insert_Flag UL CL插入标志
+New_PSA_FTEID 新PSA隧道端点
+Traffic_Detection_Rule 流量检测规则
}
EAS_IP_Replacement_Rule --> N4_Session_Modify : 承载于
EASRediscovery_Indication ..> N4_Session_Modify : 路线一使用
关键技术点： - 触发器是DNAI变更（6.3.3.1.2）。当SMF因UE移动或负载判定DNAI变化，即下发"O↔N"的映射更新，规范图6.3.3.1.2-1清晰描述了UL/DL两个方向的改写动作。 - 要求本地PSA具备深度改写能力：不只是NAT式地址翻译，还要理解"这个目的IP是某个EAS、对应到新EAS"的语义映射，因此与EAS部署信息（来自EASDF/AF）强耦合。 - 应用层会话状态同步：虽然UE无感知，但旧EAS的应用上下文必须迁移到新EAS（通常由MEC平台/AF侧的应用编排完成，3GPP信令不强制），否则新EAS从零开始服务，体验仍会断层。这是该方案的隐性依赖。
设计意图：用"数据面状态化改写"换取"控制面与UE零感知"，把中断窗口压到几乎为零，非常适合云游戏、AR/VR、工业控制等对中断极度敏感、又难以改造UE应用层重连逻辑的业务。代价是UPF实现复杂度上升、且要求应用状态可迁移。
无论走哪条路线，SMF内部的"重定位协调"逻辑可以抽象为一个有限状态机。它决定了"什么时候换、用什么方式换、换完回到什么状态"：
stateDiagram-v2
[*] --> 监听态
监听态 --> 触发判定: DNAI变更/AF通知/EAS部署变化
触发判定 --> SSC3重发现: UE可达且需更换IP
触发判定 --> EAS_IP替换: 要求无中断且UE无需感知
触发判定 --> 监听态: 判定不需重定位
SSC3重发现 --> 锚点重选: SMF发起用户面路径管理
锚点重选 --> UE重发现: 下发RA/EAS重发现指示
UE重发现 --> 旧路径释放: 新EAS会话建立
旧路径释放 --> 监听态
EAS_IP替换 --> PSA规则更新: 下发N4替换规则
PSA规则更新 --> 监听态: 双向替换生效
判定逻辑的核心输入是三件事：UE当前位置对应的DNAI、AF对中断敏感度的要求、EAS部署在两侧站点的可用性。SMF据此在"换IP+UE重连"（路线一）与"保IP+UPF改写"（路线二）之间二选一。
重定位的"触发源"往往不在SMF自己，而在应用侧。AF（Application Function）通过 NEF 订阅"流量路由影响（Traffic Influence）"，把自己对"某UE/某区域流量应走向哪个DNAI"的意图告诉5GC：
Nnef_TrafficInfluence_Create，携带目标UE/IP范围、期望DNAI、业务QoS、是否允许EAS IP替换等。这条链路把"应用层编排意图"与"5G用户面重选"打通，是运营商向垂直行业（如车联网、工业MEC）开放边缘能力的关键接口。
| 维度 | 路线一：AF Change（6.3.2） | 路线一变体：EAS重发现（6.2.2.3） | 路线二：EAS IP替换（6.3.3） |
|---|---|---|---|
| UE是否感知 | 是，需重连 | 是，需重新DNS+重连 | 否，完全透明 |
| 是否更换UE IP | 是（SSC3换锚点） | 是 | 否 |
| 是否更换EAS IP | 是 | 是 | UE侧否/网络侧是 |
| 中断窗口 | 较大（应用重连） | 中等（DNS+重连） | 近乎零 |
| UE应用改造 | 需要 | 需要 | 不需要 |
| UPF实现复杂度 | 低 | 中 | 高（状态化改写） |
| 应用状态迁移 | UE/应用层负责 | UE/应用层负责 | MEC平台/AF负责（隐性依赖） |
| 典型业务 | 一般业务 | 流媒体、CDN | 云游戏、AR/VR、工业控制 |
| 引入版本 | R17 | R17 | R18 |
tshark 中过滤 pfcp && pfcp.msg_type==5（Session Establishment Request）观察新PSA插入；再过滤 pfcp.node.report_type 与 Apply Action，定位是否携带了 UL CL 与 Traffic Detection Rule。如果看到 PDR 中携带了 FQDN 类的 SDF Filter 且绑定了 DNAI，基本可确认是边缘重定位的锚点重选。实操建议：使用项目自带
pcap-analyzer工具，以"分析EAS重定位流程"为查询，可自动关联 PFCP/DNS/N4/NAS 时序，定位哪一阶段卡住。
Q1：EAS重发现（6.2.2.3）和EAS IP替换（6.3.3）到底什么关系，能否同时用？ A：它们是两条并列的重定位路线，针对不同中断敏感度。EAS重发现要求UE重新DNS+换IP，UE有感知；EAS IP替换在数据面改写，UE无感知。一般按业务二选一。理论上两者可在同一会话的不同阶段组合（如先用IP替换稳住、再择机重发现），但标准主流程是分别定义的，组合实现需要厂商定制。
Q2：为什么R18要单独引入EAS IP替换，SSC3不够用吗？ A：SSC3是"换锚点+换UE IP"，必然要求应用层重连，对云游戏等业务中断不可接受。EAS IP替换用UPF数据面改写换取零中断与UE无感知，弥补了SSC3在中断敏感场景的短板，是R18面向AR/VR、工业控制等垂直业务的关键补丁。
Q3：DNAI在重定位里到底起什么作用？ A：DNAI是"接入哪个边缘站点/DN"的逻辑标识。SMF判断"UE现在该用哪个DNAI"，就知道流量该从哪个PSA出口、连到哪个区域的EAS池。DNAI变更就是重定位的根触发条件，AF通过NEF影响路由时也是以DNAI为参数下发意图。
Q4：EAS IP替换会不会有状态同步问题？ A：会。3GPP信令只负责把数据面流量改路到新EAS，但旧EAS上的应用会话上下文（如游戏进度、会话Token）需要由MEC平台/AF侧的应用编排迁移到新EAS，否则新EAS从零服务，体验仍会断层。这是该方案的隐性依赖，不在3GPP标准范围内。
Q5：抓包时怎么快速判断是路线一还是路线二？ A：看UE在重定位后是否换了IP并重新DNS。若UE重新发起DNS且EAS IP变了，是路线一（6.2.2.3）；若UE的EAS目的IP始终不变、但UPF两侧IP不一致（非对称改写），是路线二（6.3.3）。
本文由「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 等场景全覆盖。