# 边缘应用发现 EASDF 信令全链拆解 > 选题依据：本主题与已覆盖的「UL CL 本地分流信令机制」互补但完全不同。UL CL 解决的是"用户面流量如何被分类器引流到边缘 UPF"，而 EASDF 解决的是更上游的"UE 如何先知道边缘应用服务器（EAS）的 IP 地址"——这是一个基于 DNS 拦截与重写的发现（Discovery）机制，核心信令发生在 UE↔EASDF↔SMF 之间，遵循 TS 23.548 Section 6.2.3.2.2 与 Stage 3 接口 TS 29.556。 ## 一、为什么边缘计算需要一套独立的"发现"机制 边缘计算（MEC）的核心价值是把应用服务器（EAS，Edge Application Server）下沉到靠近用户的本地数据网络（Local DN）。但这里立刻产生一个鸡生蛋的问题： - UE 上的 App（浏览器、云游戏客户端、AR/VR 应用）通过域名（FQDN）发起业务，先要做 DNS 解析拿到服务器 IP； - 如果 DNS 仍然走远端中心 DNS，解析出来的就是中心机房的 IP，流量被引到千里之外，"边缘下沉"形同虚设； - 即使网络侧插入了 UL CL，UL CL 也只能按"已知的 IP/端口"做分流，**它本身并不知道哪个 FQDN 对应哪个本地 EAS**。 因此 Release 17 在 TS 23.548 引入了一个专门的网元——**EASDF（Edge Application Server Discovery Function）**，本质是一个被 SMF 控制的、5GC 内部的智能 DNS 解析器/代理。它的工作可以概括为一句话：**在 DNS 解析的瞬间，把"边缘 FQDN"拦截下来，由 5GC 决定返回哪个本地 EAS 的 IP，必要时顺带触发 UPF 重定位把用户面锚点搬到边缘。** 这使得对 UE 完全透明——App 用标准 DNS、用标准 socket 连接，完全不需要改代码，网络侧就把业务路由到了最近的边缘节点。这是"网络控制、应用无感"设计哲学的典型样本。 ## 二、EASDF 的架构定位与相关网元 EASDF 不是孤立工作的，它处在一条"发现链"上。下图给出 EASDF 在 5GC 中的位置以及与各网元的接口关系。 ```mermaid flowchart TD UE["UE\n(含 EDC 边缘 DNS 客户端)"] -->|"DNS Query/Response\n(FQDN→EAS IP)"| UPF subgraph FiveGC["5G 核心网"] UPF["UPF / PSA\n转发 DNS 到 EASDF"] -->|"N6 上的 DNS\n(端口53)"| EASDF EASDF["EASDF\n智能DNS解析器"] -->|"Neasdf_DNSContext\n_Create/_Update/_Delete/_Notify\n(SBI, HTTP/2)"| SMF SMF["SMF\n选择DNAI/插入UL CL/重定位PSA"] -->|"Npcf/NEF"| PCF PCF --> NEF SMF -.->|"本地配置/本地DNS"| LDNS["Local DN Server\n(EAS IP 来源)"] end NEF["NEF"] --> AF["AF / MEC 平台\n(EAS部署信息)"] UPF -->|"N6"| EAS["EAS\n(边缘应用服务器)"] ``` 下表说明各角色在本机制中的职责边界。 | 网元/功能 | 在 EAS 发现中的角色 | 关键行为 | |----------|-------------------|---------| | **UE (含 EDC)** | DNS 发起方；EDC 确保 DNS 请求发往 EASDF | 通过 OS 层 Edge DNS Client 把 App 的 DNS 指向 SMF 下发的 EASDF IP | | **UPF (PSA)** | DNS 流量中转 | 按 PDR 把目标为 EASDF IP 的 53 端口报文转发给 EASDF | | **EASDF** | 拦截+规则匹配+上报+解析/重写 | 按 DMHR 匹配 FQDN，决定上报 SMF、本地解析、转发远端、或重写 IP | | **SMF** | 发现决策中枢 | 选 DNAI、决定 EAS IP 来源、配置 DMHR、插入 UL CL/L-PSA、触发 UPF 重定位 | | **AF / NEF / PCF** | EAS 部署信息来源 | AF 经 NEF/PCF 把 EAS IP、FQDN 范围、DNAI 策略注入 SMF | | **Local DNS / EASDF 本地解析** | EAS IP 解析源 | EASDF 本地解析或查 Local DNS Server 拿到本地 EAS IP | ## 三、核心数据结构：DNS Context 与 DNS 消息处理规则（DMHR） EASDF 的一切行为都由 SMF 下发的规则驱动。SMF 在 PDU 会话粒度上为每个会话建立一个 **DNS Context**（DNS 上下文），其中挂载若干条 **DNS Message Handling Rule（DMHR，DNS 消息处理规则）**。这套数据模型定义在 TS 29.556（Neasdf 服务，Stage 3）。 下图用类图展示 DNS Context 的 IE 结构与 DMHR 的字段组成。 ```mermaid classDiagram class DnsContext { +pduSessionId : integer +dnn : string +snssai : Snssai +ueIpv4 / ueIpv6 : IpAddr +smfId : Fqdn +dnsRules : DnsRule[0..n] } class DnsRule { +dnsRuleId : string +dnsPattern : FqdnRange +scope : "QUERY"|"RESPONSE" +dnsQueryType : "A"|"AAAA"|... +action : Action +trigger : Trigger } class Action { <> RESOLVE_DNS FORWARD_DNS REPORT_DNS } class DnsContextNotify { +dnsMessage : bytes +dnsRuleId : string +dnsMessageIdentifier : string +ueId / pduSessionId } DnsContext "1" o-- "0..n" DnsRule : contains DnsRule --> Action : action EASDF ..> DnsContextNotify : 上报 SMF ``` DMHR 三种核心动作（Action）是理解整个机制的钥匙： | Action | 含义 | 触发后续 | |--------|------|---------| | **REPORT_DNS** | 命中规则后，把 DNS 报文（query 或 response）**上报 SMF** 并暂存/挂起 | SMF 基于报文决定 DNAI、EAS IP，必要时重定位 UPF，再让 EASDF 回应 | | **RESOLVE_DNS** | EASDF **本地解析**（自己或查 Local DNS）后返回 | 无需 SMF 介入，最轻量路径 | | **FORWARD_DNS** | 把 DNS 查询**转发到远端 DNS 解析器**（far DNS resolver） | 用于非边缘 FQDN，回传统中心 IP | `scope` 决定规则对查询（QUERY）还是响应（RESPONSE）生效；`trigger` 决定何时上报（查询命中即报 / 响应命中才报）。一个 EASDF 实例可同时承载多条规则，按 `dnsRuleId` 唯一标识、按下发顺序匹配。 ## 四、完整信令时序：EAS 发现 + 可选 UPF 重定位 下面这张时序图严格对应 TS 23.548 Section 6.2.3.2.2（EAS Discovery Procedure with EASDF），并叠加了可选的 PSA Change（TS 23.502 clause 4.3.5.1）。这是文章的核心。 ```mermaid sequenceDiagram participant UE participant UPF as UPF(Central PSA) participant EASDF participant SMF participant PCFNEF as PCF/NEF participant AF participant LPSA as L-PSA(Edge) Note over UE,SMF: 阶段0: PDU会话建立期间预置 DNS 规则 UE->>SMF: PDU Session Establishment Request SMF->>SMF: 选择 EASDF, 决定 EASDF IP 作为 DNS Server SMF->>EASDF: Neasdf_DNSContext_Create(dnn, snssai, pduSessionId, 初始 DMHR 集合) EASDF-->>SMF: 201 Created (DNS Context) SMF-->>UE: PDU Estab. Accept (DNS Server = EASDF IP) Note over UE,EASDF: 阶段1: DNS 拦截与上报 UE->>UPF: DNS Query (FQDN, e.g. game.edge.mnc) UPF->>EASDF: 转发 DNS Query EASDF->>EASDF: 匹配 DMHR → scope=QUERY, action=REPORT_DNS EASDF->>SMF: Neasdf_DNSContext_Notify (dnsMessage, dnsRuleId, dnsMsgId) Note over EASDF,SMF: EASDF 暂存挂起 DNS 查询, 等待 SMF 决策 Note over SMF,AF: 阶段2: SMF 决策 EAS IP / DNAI SMF->>PCFNEF: (可选) 查询 EAS 部署信息 / AF influence PCFNEF->>AF: (可选) Naf 获取 EAS IP / DNAI AF-->>PCFNEF: EAS IP, FQDN→DNAI 映射 PCFNEF-->>SMF: EAS IP + target DNAI SMF->>SMF: 确定 target DNAI Note over SMF,LPSA: 阶段3(可选): 插入 UL CL + L-PSA, UPF 重定位 SMF->>LPSA: N4 建立 PDR/FAR(分流到边缘 DN) SMF->>UPF: N4 增加 UL CL 规则 / BP Branching Point Note over EASDF,UE: 阶段4: 回应 DNS, 业务落地边缘 SMF->>EASDF: Neasdf_DNSContext_Update (指示 EAS IP 或允许解析) EASDF-->>UPF: DNS Response (EAS IP) UPF-->>UE: DNS Response UE->>LPSA: 业务连接 (直连边缘 EAS) ``` ### 关键信令消息 IE 逐条解析 **① Neasdf_DNSContext_Create（SMF→EASDF，阶段0）** 对应 TS 29.556 Section 5.2.2.2.1，创建本次 PDU 会话的 DNS 上下文。核心 IE： - `pduSessionId`：关联会话，DNS Context 是"一会话一上下文"。 - `dnn / snssai`：用于本地解析时定位 DN。 - `ueIpv4Address / ueIpv6Prefix`：EASDF 上报时携带，SMF 据此反查会话。 - `dnsRules[]`：初始 DMHR 集合，决定哪些 FQDN 走边缘发现。 **② DNS Query（UE→UPF→EASDF，阶段1）** 就是普通 DNS，但目标 IP 是 EASDF。EDC（Edge DNS Client，TS 23.548）在 UE 侧确保 App 的 DNS 用这个地址，而不是系统默认的远端 DNS。 **③ Neasdf_DNSContext_Notify（EASDF→SMF，阶段2，回调）** 这是整条链的"灵魂消息"。EASDF 命中 `REPORT_DNS` 规则后，通过 SMF 预先注册的回调 URI 上报： - `dnsMessage`：原始 DNS 报文（query 内容，含被查询的 FQDN）。 - `dnsRuleId`：命中的规则 ID，让 SMF 知道是哪条策略被触发。 - `dnsMessageIdentifier`：报文标识符（Rel-17 One-Time DNS Rule 相关 CR 引入，用于把"上报"与"后续回应"精确配对，避免多查询场景下错配）。 上报后 EASDF 把这条查询"挂起"（hold），不立即回 UE，等 SMF 给结论。 **④ SMF 决策（阶段2）** SMF 拿到 FQDN 后，决定 EAS IP 的来源有三条路径： 1. AF 经 NEF/PCF 注入的 EAS IP / FQDN-DNAI 映射（最常见，MEC 平台作为 AF）； 2. SMF 本地配置（静态映射）； 3. 让 EASDF 去 Local DNS Server 解析（`RESOLVE_DNS`）。 SMF 还要决定 `target DNAI`（目标数据网络接入标识），DNAI 是后续插入边缘 UPF 的关键。 **⑤ 可选 UPF 重定位（阶段3）** 如果当前 PSA 不在该 DNAI 的边缘，SMF 执行 PSA Change（TS 23.502 4.3.5.1）：插入 UL CL + 新的 L-PSA（Local PSA），或直接重定位锚点。注意：**EAS 发现与 UL CL 插入是两步，EAS 发现的 DNS Notify 往往就是触发 UL CL 的扳机**——这正好解释了为什么它和"UL CL 本地分流"是互补关系。 **⑥ Neasdf_DNSContext_Update（SMF→EASDF）+ DNS Response（阶段4）** SMF 把决策回灌给 EASDF：要么直接给 EAS IP 让它塞进响应，要么放行让其本地解析。EASDF 收尾把 DNS Response 发回 UE。UE 拿到边缘 EAS IP 后，业务流量自然经由刚插入的 L-PSA 落地边缘。 ## 五、EASDF 内部 DNS 消息处理状态机 TS 29.556 Section 5.2.3.2.3 定义了 EASDF 收到 DNS 消息后的处理流程。下图把这条处理逻辑抽象成状态机。 ```mermaid stateDiagram-v2 [*] --> Idle Idle --> MatchCheck : 收到 DNS 消息 MatchCheck --> Forward : 无规则命中/非边缘FQDN MatchCheck --> ResolveLocal : 命中 RESOLVE_DNS MatchCheck --> ReportHold : 命中 REPORT_DNS ReportHold --> WaitingSMF : Neasdf_Notify 上报 WaitingSMF --> ApplyIP : 收 SMF Update(给EAS IP) WaitingSMF --> ResolveLocal : 收 SMF Update(允许解析) WaitingSMF --> Forward : 收 SMF Update(放行转发) Forward --> Respond : 远端DNS返回中心IP ResolveLocal --> Respond : 本地/Local DNS解析边缘EAS IP ApplyIP --> Respond : 将EAS IP写入响应(可重写) Respond --> Idle : DNS Response 发回 UE ``` 三种"出口"殊途同归到 `Respond` 状态，差异只在 IP 的来源（中心 IP / 边缘 EAS IP / 重写后的 IP）。其中 `ApplyIP` 对应 **IP 替换机制**（TS 23.548 Section 6.7.2.5）：EASDF 先从远端 DNS 拿到中心 EAS IP 的响应，再按 SMF 指示把中心 IP 替换成边缘 EAS IP——这在 Home-Routed 漫游、V-EASDF（拜访地 EASDF）场景下尤其重要。 ## 六、EAS IP 的三种来源与 DNAI 选择 理解了时序，再聚焦"SMF 到底怎么定 EAS IP"。这是设计的精妙处——5GC 不绑定单一来源，而是组合三种： | 来源 | 触发条件 | 典型场景 | |------|---------|---------| | **AF 提供** | MEC 平台经 NEF/PCF 注入 EAS IP | 商用 MEC，AF 即 MEC 编排器，动态调度 EAS 实例 | | **本地 DNS Server 解析** | `RESOLVE_DNS`，EASDF 查 Local DNS | DN 内已有专门解析边缘 FQDN 的 DNS | | **5GC 决定（公共 EAS）** | Rel-18 Common EAS，一组 UE 共用一个 EAS | 高密并发场景，节省 EAS 实例数 | DNAI 选择同样多源：AF influence（Traffic Routing Influence，TS 23.501）、本地 OAM 配置、或签约。SMF 综合后选出离 UE 当前位置（TA/Cell）最近、且 EAS 可达的 DNAI。 ## 七、EAS Rediscovery 与移动性联动 UE 移动到新边缘节点、或当前 EAS 过载需要切换实例时，需要 **EAS Rediscovery**（重发现）。典型触发： - SMF 因 UPF 重定位到新 DNAI，主动让 UE 刷新 DNS（发 Session Modification，UE 清 DNS 缓存重查，新查询落到新 EASDF 规则 → 新 EAS IP）； - AF 侧 EAS 实例迁移，通过 PCF/NEF 更新 SMF 的 FQDN-DNAI 映射，SMF 用 `Neasdf_DNSContext_Update` 更新 DMHR。 这就要求 DMHR 可动态更新（Update/Delete 全生命周期），这正是 TS 29.556 提供 Create/Update/Delete/Notify 四个操作的原因——DNS Context 是一个**有状态、可演进的会话级资源**，而非一次性配置。 ## 八、实战连接：抓包识别与故障排查 ### 1. 抓包如何认出这条流程 在 Wireshark 中按以下层次定位： - **UE↔EASDF 的 DNS（阶段1/4）**：过滤 `dns and ip.dst == `，能看到对边缘 FQDN 的 A/AAAA 查询与响应。注意响应 IP 与"远端中心 IP"不同时，就说明发生了边缘发现/重写。 - **EASDF↔SMF 的 Neasdf SBI（阶段0/2/4）**：HTTP/2 流，关注方法：`POST`（Create DNS Context）、`PUT/PATCH`（Update 规则）、`POST`（Notify 回调）。可配合 `pcap-analyzer` 工具按 `Neasdf_DNSContext` 关键字检索。 - **SMF↔UPF 的 N4（阶段3）**：PFCP 会话修改，新增 UL CL 相关 PDR/FAR——这是 UPF 重定位的指纹。 ### 2. 常见故障点与排错思路 | 现象 | 可能根因 | 排查方向 | |------|---------|---------| | UE 解析到的始终是中心 IP，业务未走边缘 | DMHR 未下发/未命中；EASDF IP 未作为 DNS Server 下发 | 查 PDU Estab Accept 中 DNS Server 字段；查 EASDF 收到的 DMHR 集合 | | DNS 响应时延陡增 | REPORT_DNS 路径下 SMF 决策慢、AF/PCF 链路抖动 | 看 Notify→Update 的端到端时延；评估改用 RESOLVE_DNS | | 业务断流 | UPF 重定位与 DNS 响应时序错配，UE 拿到 EAS IP 但 L-PSA 尚未就绪 | 检查 SMF 是否在 Update EASDF 前已完成 N4 下发 | | 漫游下发现错误 EAS | Home-Routed 时未用 V-EASDF / IP 替换配置缺失 | 核对 V-EASDF 与 Local DNS Server 的 IP replacement 规则 | ## 九、与相关机制对比 | 维度 | EASDF 发现（本文） | 传统远端 DNS | UL CL 本地分流 | LADN | |------|------------------|------------|--------------|------| | 解决问题 | "UE 拿到哪个 EAS IP" | "拿到哪个服务器 IP" | "流量走哪条 UPF 路径" | "会话能否接入本地 DN" | | 控制主体 | SMF + EASDF | 运营商/公共 DNS | SMF（按 DNAI 插 UL CL） | SMF + AMF | | 对 UE 透明度 | 完全透明（标准 DNS） | — | 完全透明 | 需 UE 发起特定 DNN | | 是否动态重发现 | 是（Update/Notify） | 否 | 间接（随 PSA 变化） | 否 | | 关键 TS | TS 23.548 / 29.556 | RFC 系列 | TS 23.501/23.502 4.3.5 | TS 23.501 | 可以看出四者层次不同、可叠加：LADN 圈定本地会话 → EASDF 发现边缘 EAS IP →（动态）插入 UL CL 把流量引到 L-PSA → UE 直连边缘 EAS。EASDF 是这条价值链上的"指路牌"。 ## 常见问题 **Q1：EASDF 和普通 DNS Resolver 有什么本质区别？** A：普通 DNS Resolver 只做"域名→IP"的无状态映射；EASDF 是**有状态、被 SMF 控制**的解析器。它持有按 PDU 会话划分的 DNS Context，按 SMF 下发的 DMHR 决定拦截/上报/重写/本地解析，并能把 DNS 事件反向通知 SMF 触发网络侧行为（如 UPF 重定位）。它是"5GC 内的智能 DNS"，而非纯转发解析器。 **Q2：为什么需要 REPORT_DNS 把查询上报 SMF，而不是 EASDF 直接解析？** A：直接解析（RESOLVE_DNS）是最快路径，但 SMF 只有在收到 FQDN 时才能结合 UE 实时位置（TA/Cell）、AF 提供的 EAS 部署状态来选最合适的 DNAI 和 EAS 实例，并据此决定要不要重定位 UPF。上报让"应用层发现"与"网络层路由优化"在同一决策点收敛，这是边缘计算"网络控制"设计的核心。 **Q3：EAS 发现一定会触发 UPF 重定位吗？** A：不一定。若当前 PSA 已在目标 DNAI，则无需重定位，SMF 只需让 EASDF 返回 EAS IP；只有当锚点不在边缘、或需要插入 UL CL/BP 时才执行 PSA Change（TS 23.502 4.3.5.1）。重定位是 EAS 发现的"可选第二动作"，频率取决于初始 PDU 会话锚点选址。 **Q4：Home-Routed 漫游下 EASDF 怎么部署？** A：Rel-17/18 引入 V-EASDF（拜访地 EASDF）与 Local DNS Server 的 IP 替换机制（TS 23.548 Section 6.7.2.5），让 VPLMN 也能就近发现边缘 EAS，而无需把所有 DNS 流量绕回 HPLMN，兼顾本地化与归属地控制。 **Q5：定义 Neasdf 服务接口的到底是哪个 TS？** A：是 **TS 29.556**（5G System; Edge Application Server Discovery Function (EASDF) Services; Stage 3）。这一点常被误记为 29.538 或 29.548——前者是别的服务，后者属 NEF 相关。Stage 2 机制在 TS 23.548，Stage 3 接口（DNS Context Create/Update/Delete/Notify 及 IE）在 TS 29.556，二者配套使用。 ## 参考来源 1. [3GPP TS 23.548 V18.8.0 — 5G System Enhancements for Edge Computing; Stage 2](https://www.etsi.org/deliver/etsi_ts/123500_123599/123548/18.08.00_60/ts_123548v180800p.pdf) — Section 6.2.3.2.2（EAS Discovery Procedure with EASDF）、6.7.2.5（V-EASDF/Local DNS Server IP replacement） 2. [3GPP TS 29.556 — EASDF Services; Stage 3（Neasdf_DNSContext_Create/Update/Delete/Notify）](https://www.3gpp.org/ftp/Specs/archive/29_series/29.556) — Section 5.2.2.2.1、5.2.3.2.3（incoming DNS message processing） 3. [3GPP TS 23.502 — Procedures for the 5G System](https://www.3gpp.org/dynareport/23502.htm) — clause 4.3.5.1（PSA Change / UPF relocation for edge） 4. [3GPP TS 23.558 — Architecture for enabling Edge Applications (EDGE-APP)](https://www.3gpp.org/dynareport/23558.htm) — EASDF 部署模型与 ECS 配置 5. [iTeCSpec TS 23.548 Section 6.2.3.2.2 可读版参考](https://itecspec.com/3gpp/23.548/s/6.2.3.2.2) 及 [TS 29.556 Section 5.2.3.2.3](https://itecspec.com/3gpp/29.556/s/5.2.3.2.3) — DNS 规则匹配与上报流程图 --- > 本文由「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 等场景全覆盖。