首页 › slicing-mec › 边缘应用发现EASDF信令拆解

边缘应用发现 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）。但这里立刻产生一个鸡生蛋的问题：

因此 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 中的位置以及与各网元的接口关系。

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 的字段组成。

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 {
        <<enumeration>>
        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）。这是文章的核心。

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 消息后的处理流程。下图把这条处理逻辑抽象成状态机。

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 中按以下层次定位：

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 — 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） — 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 — clause 4.3.5.1（PSA Change / UPF relocation for edge）
  4. 3GPP TS 23.558 — Architecture for enabling Edge Applications (EDGE-APP) — EASDF 部署模型与 ECS 配置
  5. iTeCSpec TS 23.548 Section 6.2.3.2.2 可读版参考 及 TS 29.556 Section 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 等场景全覆盖。

51学通信知识星球海报-扫码加入

📎 本分类最新文章