聚焦 3GPP TS 23.558（Rel-18）Clause 8.5 / 8.8 / 8.9，解析边缘应用服务器（EAS）发现、应用上下文重定位（ACR）三阶段信令，及其与5GC UPF重定位的协同。
5G边缘计算（MEC）的第一步是把应用服务器（EAS）下沉到离UE最近的边缘数据中心（Edge Data Network, EDN），这一步由 TS 23.548 定义的用户面机制（UPF + UL CL本地分流）解决。但真正的难点不在"部署"，而在移动：当UE从边缘站点A移动到边缘站点B，原本锚定在A的EAS若不随之迁移，端到端时延将瞬间劣化（回传到中心云），AR/VR、云游戏、车联网协同等对时延敏感的业务体验会立刻崩溃。
为此，3GPP在 Rel-17 引入了EDGEAPP（Enabler for Edge Applications）架构，并在 TS 23.558 中定义了一套独立于底层UPF重定位的、应用层的服务连续性机制——应用上下文重定位（Application Context Relocation, ACR）。它解决的是一个核心问题：如何在不中断应用会话的前提下，把UE正在使用的EAS从源边缘节点迁移到目标边缘节点，并把应用上下文（Application Context）一并搬过去。
本文基于 TS 23.558 V18.10.0，聚焦 EAS 发现（Clause 8.5）与 ACR（Clause 8.8）这两条核心信令链，逐消息拆解 IE、设计意图、以及与5GC UPF重定位（SSC模式3）的协同关系。
EDGEAPP的核心设计思想是引入一层边缘使能层（Edge Enabler Layer, EEL），它独立于应用本身，专门负责边缘的"发现—连接—重定位"控制面。EEL由以下功能实体组成：
| 功能实体 | 全称 | 部署位置 | 核心职责 |
|---|---|---|---|
| EAC | Edge Application Client | UE | 边缘应用客户端，产生/消费应用面数据 |
| EEC | Edge Enabler Client | UE | 边缘使能客户端，EEL在UE侧的代表，发起EAS发现与ACR |
| EAS | Edge Application Server | Edge DN | 边缘应用服务器，承载实际业务逻辑 |
| EES | Edge Enabler Server | Edge DN | 边缘使能服务器，EEL在边缘侧的代表，管理EAS发现与ACR |
| ECS | Edge Configuration Server | 5GC或运营商域 | 边缘配置服务器，为EEC提供EES连接信息 |
EEL通过一组参考点（Reference Points）相互连接，定义于 TS 23.558 Clause 4.4：
graph TD
subgraph UE侧
EAC[EAC 边缘应用客户端]
EEC[EEC 边缘使能客户端]
end
subgraph 边缘数据网络 Edge DN
EES[EES 边缘使能服务器]
EAS[EAS 边缘应用服务器]
end
subgraph 5G核心网 / 配置域
ECS[ECS 边缘配置服务器]
NF[5GC NFs<br/>NEF/PCF/UDM/BSF/SMF]
end
EAC ---|EDGE-3 使能交互| EEC
EAC -.->|EDGE-5 应用面| EAS
EEC <= == EDGE-1 发现/ACR控制 ==> EES
EEC <= == EDGE-9 获取EES连接信息 ==> ECS
EES <= == EDGE-2 能力开放/影响路由 ==> NF
EES ---|EDGE-4 应用上下文| EAS
EES <= == EDGE-8 配置 ==> ECS
EES <-.->|EDGE-6 跨EES/ACR| EES2[对端 EES]
ECS -.->|EDGE-7| NF
| 参考点 | 端点 | 接口性质 | 主要用途 |
|---|---|---|---|
| EDGE-1 | EEC ↔ EES | 应用层SBI | EAS发现、边缘应用上下文管理、ACR通知（控制面核心） |
| EDGE-2 | EES ↔ 5GC | SBI（NEF/PCF/UDM/BSF） | EES以AF身份开放QoS、影响路由、获取用户/移动事件 |
| EDGE-3 | EEC ↔ EAC | UE内部 | 向EAC暴露EEL能力（如目标EAS端点变更通知） |
| EDGE-4 | EES ↔ EAS | 应用层 | EES获取/转移应用上下文（ACR关键接口） |
| EDGE-5 | EAC ↔ EAS | 应用面 | 实际业务数据通道（EDGE-5不是EEL专属，是应用自定义） |
| EDGE-6 | EES ↔ EES | SBI | 跨边缘站点的ACR协同（目标EAS发现、EEC上下文推送） |
| EDGE-9 | EEC ↔ ECS | SBI | ECS为EEC提供EES连接信息（配置发现入口） |
设计意图：这套分层解耦的关键在于——应用面（EDGE-5）完全由业务自定义，而所有"边缘性"的复杂性（发现哪个EAS、何时迁移、上下文怎么搬）全部收敛到EEL的标准化接口EDGE-1/4/6/9上。这意味着任何第三方应用只要对接EEC/EES的标准API，就能获得运营商级的边缘移动性保障，而无需自己实现移动性逻辑。
UE上的EAC要使用某个边缘应用，第一步不是直接连EAS，而是让EEC先"找到"当前最适合的EAS。整个发现分为两个阶段：先找EES（ECS Provisioning），再通过EES找EAS（EAS Discovery）。
EEC必须先知道"该连哪个EES"。EEC通过 EDGE-9 向 ECS 发起配置请求。EES连接信息的获取途径在 TS 23.558 中定义了多种：UE本地预配置、通过PCF下发的URSP规则、或通过DNS解析ECS地址后走EDGE-9。ECS返回的信息至少包含：一个或多个 EES连接信息（EES Connection Info），即EES的URI/IP，以及该EES所属EDN的服务范围标识。
这一步的本质是配置发现入口——ECS扮演"边缘DNS/目录"的角色，告诉UE"你当前位置应该去敲哪个EES的门"。
EEC拿到EES地址后，通过 EDGE-1 向 EES 发起 EAS Discovery Request（TS 23.558 Clause 8.5.3.2）。EES根据EEC上报的应用画像、UE位置等，在本地EAS部署信息库中匹配，返回 EAS Discovery Response（Clause 8.5.3.3），其中包含候选EAS列表及其 EAS Profile。
sequenceDiagram
autonumber
participant EAC as EAC<br/>(UE)
participant EEC as EEC<br/>(UE)
participant ECS as ECS
participant EES as EES<br/>(Edge DN)
participant EAS as EAS
EAC->>EEC: 应用请求: 需要EAS (AC Profile, AC ID)
EEC->>ECS: EDGE-9: EES连接信息请求 (UE位置/PLMN)
ECS-->>EEC: EES连接信息 (EES URI/IP, EDN范围)
EEC->>EES: EDGE-1: EAS Discovery Request<br/>(EEC ID, AC Profile, EAS发现过滤器, UE位置)
EES->>EES: 匹配EAS部署信息<br/>(EAS类型/服务区/负载)
EES-->>EEC: EAS Discovery Response<br/>(候选EAS列表 + EAS Profile)
EEC->>EAC: EDGE-3: 返回目标EAS端点
EAC->>EAS: EDGE-5: 建立应用会话
Note over EES,EEC: 服务区/负载变化时<br/>EES可主动推送<br/>EAS Discovery Notification (8.5.3.6)
EAS Discovery Request（Clause 8.5.3.2）核心 IE：
| IE名称 | 含义 | 设计作用 |
|---|---|---|
| EEC ID | 边缘使能客户端标识 | 关联EEC上下文，ACR时用于跨EES寻址 |
| AC Profile | 应用客户端画像（AC ID、AC类型、所需EAS类型） | 决定匹配哪类EAS |
| EAS Discovery Filter | 发现过滤器（EAS提供者、EAS类型、应用组ID） | 精准筛选候选EAS |
| UE Location | UE当前位置（TAI/小区） | 服务区匹配，避免返回UE覆盖不到的EAS |
| Required EAS Deployment Info | 所需EAS部署属性（如要求本地性） | 区分本地EAS与中心EAS |
EAS Profile（含于EAS Discovery Response）核心 IE：
| IE名称 | 含义 |
|---|---|
| EAS Identity | EAS唯一标识 |
| EAS Endpoint | EAS连接端点（IP/FQDN/端口）—EAC连接目标 |
| EAS Provider | EAS提供者标识（运营商/第三方） |
| EAS Type | EAS类型（对应某种应用） |
| Service Area | EAS服务区（超出即需ACR） |
| Service Continuity | 是否支持服务连续性（决定能否做ACR） |
| EAS Schedule | EAS可用时间窗 |
| Service API(s) | EAS暴露的服务API（EDGE-4能力开放） |
设计意图——为什么发现与连接分离？ 把"EES发现"（位置相关、低频）与"EAS发现"（应用相关、可高频）拆开，使得UE移动到新区域时只需重新执行轻量的ECS查询换一个EES，而EAS发现的过滤逻辑由EES承担——UE无需维护庞大的EAS目录，所有边缘拓扑知识集中在网络侧的EES/ECS上。这与5G"控制面集中、终端轻量化"的整体哲学一致。
此外，Clause 8.5.3.6 定义了 EAS Discovery Notification：当EES侧感知到更优EAS加入、或当前EAS即将失效，可主动通过 EDGE-1 推送给EEC，触发后续的ACR。这是"网络驱动重定位"的入口。
ACR是EDGEAPP最核心、也最复杂的信令流程。它把UE正在使用的源EAS（S-EAS）迁移到目标EAS（T-EAS），并保证应用会话连续。TS 23.558将ACR划分为三个明确的阶段。
flowchart TD
A[ACR决策发起<br/>Decision Phase] -->{由谁发起?}
A -->|EEC发起| B1[ACR Initiation by EEC<br/>UE检测移动/连接劣化]
A -->|源EAS发起| B2[ACR Initiation by Source EAS<br/>应用层感知/到达服务区边界]
A -->|源EES发起| B3[ACR Initiation by Source EES<br/>网络策略/负载]
B1 --> C
B2 --> C
B3 --> C
C[ACR准备阶段<br/>Preparation Phase] --> C1[Discover Target EAS<br/>Clause 8.8.3.2]
C1 --> C2[源EAS取回应用上下文<br/>EDGE-4]
C2 --> C3[上下文转移到目标EAS<br/>源EES-EDGE-6-目标EES-EDGE-4-T-EAS]
C3 --> D
D[ACR执行阶段<br/>Execution Phase] --> D1[源EES通知EEC<br/>目标EAS端点 + 目标EES信息]
D1 --> D2[EEC Context Push到目标EES<br/>Clause 8.9.2.3]
D2 --> D3[EAC重连T-EAS<br/>EDGE-5]
D3 --> D4[源EAS释放资源]
谁来判断"该迁移了"？TS 23.558定义了三种发起方，这是ACR设计的精妙之处：
三种发起路径最终都汇聚到源EES，由源EES统一调度后续准备阶段。这种多发起方汇聚到单一协调者（源EES）的设计，避免了多方决策冲突。
这是ACR的技术核心，定义于 Clause 8.8.3.2（Discover Target EAS procedure）。源EES需要为目标EAC找到一个合适的T-EAS。流程如下：
Application Context（应用上下文） 是ACR能保证业务连续的关键载体，它包含让目标EAS"无缝接手"所需的全部状态信息：源EAS端点、UE/EAC地址信息、应用会话标识、应用层状态句柄、QoS需求等。本质上它是源EAS把"我对这个UE做了什么"打包交给T-EAS。
准备就绪后进入执行：
sequenceDiagram
autonumber
participant EEC as EEC (UE)
participant SEES as 源EES
participant TEES as 目标EES
participant SEAS as 源EAS (S-EAS)
participant TEAS as 目标EAS (T-EAS)
Note over EEC,SEES: ① 决策阶段(示例: EEC发起)
EEC->>SEES: EDGE-1: ACR请求(UE位置/原因)
Note over SEES,TEAS: ② 准备阶段
SEES->>TEES: EDGE-6: Discover Target EAS(UE位置/应用)
TEES-->>SEES: 候选T-EAS + EAS Profile
SEES->>SEAS: EDGE-4: 取回Application Context
SEAS-->>SEES: Application Context(会话状态)
SEES->>TEES: EDGE-6: 转移Application Context
TEES->>TEAS: EDGE-4: 建立T-EAS会话状态
TEAS-->>TEES: 就绪确认
Note over SEES,EEC: ③ 执行阶段
SEES-->>EEC: EDGE-1: ACR通知(T-EAS端点 + 目标EES信息)
EEC->>TEES: EDGE-1: EEC Context Push(8.9.2.3)
TEES-->>EEC: 注册成功
EEC->>TEAS: (经EAC, EDGE-5) 业务重连到T-EAS
SEES->>SEAS: EDGE-4: 释放S-EAS资源
设计意图——为什么上下文要走EES中转而非EAS直连？ EAS之间通常没有标准化接口（EDGE-5只到UE），且不同EAS可能跨运营商/跨厂商。把上下文转移的协调权交给标准化功能实体EES（经EDGE-4/EDGE-6），既保证接口可互通，又让运营商（通过EES）对迁移过程有完整的可见性和管控权——这是运营商主导边缘生态的关键控制点。
ACR只迁移了"应用服务器"，但要让端到端时延真正最优，用户面路径（UPF）也必须跟着优化。这里存在两种典型场景，理解二者的区别是排错的关键。
| 维度 | EAS重定位（无UPF重定位） | EAS重定位 + EDN/UPF重定位 |
|---|---|---|
| 触发条件 | 目标EAS在同一EDN内（同UPF锚点） | 目标EAS在另一EDN，需换UPF |
| 用户面变化 | 仅更新UL CL/traffic steering规则 | 新PDU会话 + 新PSA（SSC模式3） |
| 5GC参与 | EES经EDGE-2影响路由（轻量） | SMF主导PSA重选，EAS重定位与其耦合 |
| EAS端点变化 | 变 | 变 |
| UE IP变化 | 不变 | 可能变（SSC3新会话） |
| 时延影响 | 小 | 较大（含新PDU会话建立） |
| 典型时序 | ACR先于/独立于UPF调整 | UPF重定位与ACR需协同，EES作为AF感知 |
EES作为AF的能力（EDGE-2） 是连接EEL与5GC的桥梁。EES以应用功能（AF）身份，通过 NEF 调用以下能力（与 TS 23.502 5.6.7 AF influence on routing / Nnef_TrafficInfluence 对应）：
协同设计意图：TS 23.558刻意把ACR（应用层）与UPF重定位（传输层）解耦为两个可独立、也可协同的流程。当EAS迁到同一EDN，仅靠EDGE-2的traffic influence微调UL CL即可，开销极小；当必须跨EDN，则触发5GC的SSC模式3 PDU会话重建（PSA变更），此时EEC会感知到新的PDU会话，ACR在新会话上完成EAS重连。这种分层让运营商能按部署密度灵活选择最优策略。
EDGEAPP接口（EDGE-1/4/6/9）均为应用层SBI/HTTP接口，在用户面或边缘节点抓包可见：
/eees-eas-discovery/、/eec-context/、ACR相关 /ac-relocation 等资源。可通过UE侧抓包识别EAS Discovery Request / Response 与 ACR Notification。Q1：ACR和5G的SSC（会话与服务连续性）模式是什么关系？ A：二者是不同层面的连续性机制。SSC模式（TS 23.502）是传输层/PDU会话层的连续性，决定UE IP和PSA是否随移动变化（SSC模式1保持锚点，模式3换锚点换IP）；ACR是应用层的连续性，决定UE连哪个EAS、应用上下文如何迁移。二者可独立运作，也可协同：跨EDN的EAS迁移常伴随SSC模式3的PSA重选，此时ACR与PDU会话重建需在时序上配合。
Q2：ACR为什么需要"Discover Target EAS"单独成一步，不能直接迁？ A：因为目标EAS的存在性、负载、服务区都是动态的，且可能由对端EES管理。Discover Target EAS（8.8.3.2）通过EDGE-6/ECS确保迁移前先确认一个真正可用、且能服务UE新位置的T-EAS，避免"迁过去才发现没资源"的回滚代价。
Q3：EEC Context Push（8.9.2.3）和Application Context Transfer有何区别？ A：两者粒度不同。Application Context是EAS级的应用会话状态（源EAS→目标EAS），保证业务数据连续；EEC Context是EEC在EES上的注册/会话上下文（EEC→目标EES），建立EEC与新EES的EDGE-1控制关系。前者保业务，后者保控制面接管，缺一不可。
Q4：EDGEAPP（TS 23.558）和ETSI MEC是竞争关系吗？ A：互补而非竞争。ETSI MEC（GS MEC 003等）定义边缘平台与运行环境（MEP/MEPM/MEAO）；3GPP EDGEAPP定义跨3GPP网络的边缘应用使能与移动性标准接口（EEL）。业界普遍将EES/ECS与MEC平台做映射融合，使3GPP的标准化移动性能力能调度ETSI MEC上的应用。
Q5：Rel-18对EDGEAPP有哪些增强？ A：Rel-18引入了应用组（Application Group）机制——同一应用组的多个EAS可被作为一组发现/迁移，保证多组件边缘应用（如渲染+逻辑分离）的协同连续性；并增强了EDGE-2与5GC事件暴露的联动，使ACR决策更依赖实时网络状态。Rel-19进一步向联邦漫游与边缘节点共享（Federation/Edge Node Sharing）演进。
本文由「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 等场景全覆盖。