5G EASDF 边缘应用发现 DNS 机制全链拆解

一、问题起源：为什么传统 DNS 无法支撑 MEC

在 5G 边缘计算（MEC）场景下，应用服务器（Edge Application Server, EAS）被下沉部署到多个分布式边缘数据中心。UE 访问应用的第一步是域名解析——拿到 EAS 的 IP 地址。但传统 5G 网络里，UE 配置的 DNS server 通常是运营商中心 DNS 或互联网 DNS（如 8.8.8.8），它会返回一个与 UE 物理位置无关、全局一致的 IP。结果是：位于北京的 UE 和位于广州的 UE，解析同一个 edge.app.com 得到同一个 IP，流量全部汇聚到同一台中心 EAS，边缘节点形同虚设，时延也无法收敛。

3GPP 在 Rel-16 引入了边缘计算框架（TS 23.501 clause 5.13），定义了 AF influence、DNAI（Data Network Access Identifier）、UL CL/BP（Uplink Classifier / Branching Point）、本地 PSA（PDU Session Anchor）等概念，但"如何让 UE 拿到正确的、就近的 EAS IP" 这一关键问题仍然悬而未决——SMF 需要先知道 UE 想访问哪个应用，才能决定往哪个边缘站点分流，而"想访问哪个应用"这个意图，恰好就藏在 UE 发出的 DNS Query 的 FQDN 里。

Rel-17 在 TS 23.548 中引入了一个新的核心网网元——EASDF（Edge Application Server Discovery Function），专门解决这个"鸡生蛋"问题。它的核心思想是：把 UE 的 DNS resolver 从外部 DNS 搬进 5GC，由 SMF 可编程地控制它，让 DNS 解析与流量重定向（traffic steering）协同工作。 本文聚焦 TS 23.548 clause 6.2.3.2.2「EAS Discovery Procedure with EASDF」，逐信令拆解这一机制。

二、EASDF 的架构定位与核心能力

EASDF 本质上是一个受 SMF 控制的 DNS resolver / forwarder。它对外表现为 UE 的 DNS server（UE 通过 DHCPv4/DHCPv6/PCO 把 EASDF IP 作为 DNS server 配置），对内通过 SBI 接口与 SMF 双向交互。

graph LR
    UE[UE] -->|DNS Query UDP/53| UPF[UPF-PSA]
    UPF -->|N4检测转发| EASDF[EASDF]
    EASDF -->|上游转发| CDNS[Central/External DNS]
    SMF[SMF] <-->|Neasdf SBI<br/>下发DNS规则/接收DQI·DAI| EASDF
    SMF -->|N4会话修改| UPF
    SMF -.->|NEF| AF[AF / EAS部署信息EDI]
    EASDF -->|DNS Response| UPF
    UPF -->|解析结果| UE
    style EASDF fill:#ffe4b5,stroke:#d2691e,stroke-width:2px

EASDF 的三条核心能力，恰好对应 SMF 对它的三类控制：

1. 可编程解析：SMF 用「DNS Rule」告诉 EASDF——遇到什么样的 FQDN，应该转发给哪个上游 DNS、本地解析、丢弃还是上报。
2. 事件上报：EASDF 把命中的 DNS Query（DQI）和 DNS Answer（DAI）回传给 SMF，让控制面"看见"数据面的解析结果。
3. 上游可寻址：EASDF 既可充当纯 forwarder（透传给中心 DNS），也可作为 resolver 本地应答（Rel-17 后期 / Rel-18 增强，支持 EAS IP address range 匹配后的本地构造响应）。

EASDF 与 SMF 之间的服务化接口定义在 TS 29.556（Neasdf 服务），核心服务操作是 Neasdf_DNSContext：

三、核心机制：DNS Rule 结构与动作语义

EASDF 的所有"智能"都封装在 DNS Rule 里。SMF 在 PDU 会话生命周期内可动态增删改这些规则（TS 29.556 定义了完整的 CRUD）。一个 DNS Rule 的结构如下（数据类型定义见 TS 29.571 与 TS 29.556）：

graph TD
    R["DNS Rule"] --> R1["dnsRuleId（唯一标识）"]
    R --> R2["dnsRulePriority（匹配优先级）"]
    R --> R3["dnsRuleStatus<br/>Active / Inactive"]
    R --> M["Match Criteria"]
    M --> M1["dnsDomainName<br/>FQDN（支持通配符）"]
    M --> M2["dnsQueryType<br/>A / AAAA / SRV 等"]
    R --> A["Action List（可组合）"]
    A --> A1["DISCARD 丢弃"]
    A --> A2["FORWARD + 上游 DNS"]
    A --> A3["RESOLVE_LOCALLY 本地解析"]
    A --> A4["REPORT_DNS_QUERY 上报查询"]
    A --> A5["REPORT_DNS_ANSWER<br/>+ EAS IP address range"]
    style A5 fill:#ffd,stroke:#cc8800

关键 IE 参数说明：

一个特别精妙的设计是 REPORT_DNS_ANSWER 配套的 EAS IP address range：DNS Answer 里可能返回多个 IP，但只有落在 SMF 预配的 EAS IP range 内的才是真正的边缘服务器。EASDF 用 range 做二次过滤，避免把 CDN 缓存节点、监控探针等无关 IP 上报给 SMF，造成误分流。

四、完整信令时序：EAS 发现全流程

下面按 TS 23.548 clause 6.2.3.2.2 的定义，拆解一次完整的边缘 EAS 发现。整个流程可划分为预配置阶段、DNS Query 触发阶段、流量重定向阶段。

sequenceDiagram
    autonumber
    participant UE
    participant UPF as UPF(初始PSA)
    participant SMF
    participant EASDF
    participant CDNS as 中心DNS
    participant LUPF as 本地PSA+UL CL

    rect rgb(235,245,255)
    Note over UE,EASDF: 阶段① PDU会话建立期 DNS规则预配
    UE->>SMF: PDU Session Establishment Request
    SMF->>EASDF: Neasdf_CreateContext<br/>(DNS Rule#1: FORWARD→中心DNS)
    SMF->>EASDF: DNS Rule#2: REPORT_DNS_QUERY<br/>(match *.mec.operator.com)
    SMF->>EASDF: DNS Rule#3: REPORT_DNS_ANSWER<br/>(+ EAS IP range)
    SMF->>UPF: N4会话建立:DNS检测规则→转发EASDF
    SMF-->>UE: PDU Estab Accept<br/>(DNS Server = EASDF IP)
    end

    rect rgb(255,250,235)
    Note over UE,CDNS: 阶段② DNS Query触发DQI上报
    UE->>UPF: DNS Query(FQDN=game.mec.operator.com)
    UPF->>EASDF: 转发DNS Query(UDP/53)
    EASDF->>EASDF: 命中Rule#2→上报
    EASDF->>SMF: DQI Notify<br/>(FQDN, UE IP, qType)
    EASDF->>CDNS: 转发DNS Query(Rule#1)
    CDNS-->>EASDF: DNS Response(EAS IP=192.0.2.10)
    EASDF->>EASDF: 命中Rule#3,IP∈range→上报
    EASDF->>SMF: DAI Notify(EAS IP=192.0.2.10)
    EASDF-->>UPF: DNS Response(EAS IP)
    UPF-->>UE: DNS Response
    end

    rect rgb(240,255,240)
    Note over SMF,LUPF: 阶段③ SMF流量重定向
    SMF->>SMF: 根据DAI选择就近DNAI<br/>+ 本地PSA + 插入UL CL
    SMF->>LUPF: N4会话修改(插入UL CL/本地PSA)
    Note over UE,LUPF: UE业务流量经UL CL分流到边缘EAS
    UE->>UPF: 业务报文→命中UL CL
    UPF->>LUPF: 本地分流到边缘EAS(192.0.2.10)
    end

逐步 IE 解析

阶段① —— DNS 规则预配（步骤 2-6）

PDU 会话建立时，SMF 在 SM Policy（PCF 下发）或本地配置/AF 经 NEF 提供的 EAS Deployment Information（EDI，clause 6.2.3.4）驱动下，决定该会话启用 EASDF。SMF 通过 Neasdf_DNSContext_Create 一次性下发三条规则：

• Rule#1（FORWARD）：默认兜底，所有 DNS Query 透传到中心 DNS，保证非边缘应用的解析行为不变。
• Rule#2（REPORT_DNS_QUERY）：匹配运营商边缘应用域名（如 *.mec.operator.com），命中即向 SMF 上报 DQI。这让 SMF 在 DNS 解析完成之前就提前获知 UE 的访问意图。
• Rule#3（REPORT_DNS_ANSWER）：携带 EAS IP range，DNS Answer 命中即上报 DAI。

同时，SMF 在 N4 会话建立消息里给 UPF 下发包检测规则（PDR）：目的端口 53 的 UDP 报文检测到后，转发到 EASDF。SMF 在 PDU Establishment Accept 中通过 PCO/DHCP 把 EASDF 的 IP 作为 UE 的 DNS server 下发给 UE——这一步至关重要，它确保 UE 后续所有 DNS Query 都流向 EASDF 而非外部 DNS。

阶段② —— DNS Query 触发 DQI/DAI 双上报（步骤 7-13）

UE 发起 DNS Query(game.mec.operator.com)，UPF 按 N4 规则转发给 EASDF。EASDF 做两次匹配：

• DQI 上报：Query 命中 Rule#2，EASDF 通过 callback 向 SMF 上报 DNS Query Information，核心字段是 FQDN、UE IP address、DNS query type，可能还携带 EDNS Client Subnet（ECS）option 中的 UE IP prefix（Rel-18 增强，用于让上游 DNS 做更精细的地理解析）。SMF 收到 DQI 后，可提前开始本地 PSA 的选择准备工作。
• DAI 上报：中心 DNS 返回 Answer，IP=192.0.2.10 命中 Rule#3 的 EAS IP range，EASDF 上报 DNS Answer Information，核心字段是 解析出的 EAS IP address（可多个）、关联的 FQDN、DNS response 中的 TTL。

注意：EASDF 在上报的同时不阻塞正常 DNS 响应回送给 UE，UE 的 DNS 解析时延几乎不受影响。

阶段③ —— SMF 流量重定向（步骤 14-17）

SMF 收到 DAI 后，结合 EAS IP → DNAI 映射（来自 EDI）、UE 当前位置（TA/Cell），选择一个就近的本地 PSA，并插入 UL CL UPF。SMF 通过 N4 Session Modification 给 UPF 下发新的 PDR/FAR，使目的 IP 为 192.0.2.10 的上行报文经 UL CL 分流到本地 PSA，进而经 N6 到达边缘 EAS。此后 UE 与 EAS 的应用层连接（TLS/QUIC）直接走本地路径，时延大幅下降。

五、DQI 与 DAI：控制面看见数据面的桥梁

DQI（DNS Query Information）和 DAI（DNS Answer Information）是 EASDF 机制的灵魂。它们解决了一个根本性的信息不对称：SMF 在控制面，根本"听不见"UE 与 DNS server 之间的对话。

graph TD
    subgraph 控制面感知
    SMF[SMF] -->|需要决策: 选哪个边缘站点| DEC{流量重定向}
    end
    subgraph 数据面事实
    UE -->|FQDN意图| DNS[DNS交互]
    DNS -->|EAS IP结果| UE
    end
    DQI[DQI: FQDN+UE IP] -.上报.-> SMF
    DAI[DAI: EAS IP+TTL] -.上报.-> SMF
    DEC -->|DNAI选择依据| OUT[插入UL CL/本地PSA]
    style DQI fill:#ffd
    style DAI fill:#ffd

DQI 与 DAI 配合的意义在于双保险：DQI 让 SMF 抢跑（提前选 PSA、准备 N4 规则），DAI 给出确定性的"最终答案"（精确到 IP）。在某些部署中，SMF 可以只用 DAI（省去 DQI），也可以两者都用（追求最低重定向时延）——这正是通过组合不同 Action 的 DNS Rule 灵活实现的。

六、DNS Rule 生命周期状态机

一条 DNS Rule 在其生命周期内经历如下状态转换，理解这个状态机对排错至关重要（"为什么 SMF 改了规则 EASDF 没生效？"往往就是状态问题）：

stateDiagram-v2
    [*] --> Provisioned: SMF Create/Update下发
    Provisioned --> Active: dnsRuleStatus=Active
    Active --> Matched: 收到DNS消息,命中criteria
    Matched --> Executing: 执行Action(FORWARD/REPORT...)
    Executing --> Active: 非One-Time规则,继续匹配
    Executing --> Expired: One-Time规则,匹配1次后失效
    Active --> Inactive: SMF更新Status=Inactive
    Inactive --> Active: SMF重新激活
    Expired --> [*]
    Active --> Deleted: SMF删除/会话释放
    Deleted --> [*]

三类典型触发组合对应的场景：

七、设计意图深度剖析

1. 为什么是 DNS 而不是直接让 SMF 配置 EAS IP？ 因为应用层（浏览器/App）天然通过 FQDN 寻址，5GC 不能、也不应替应用做 DNS 决策。EASDF 的设计哲学是"拦截而不替代"——它依旧让 UE 走标准 DNS 流程，只在 5GC 内部加了一层可观测、可编程的解析代理。这保证了与终端和应用生态的完全兼容。

2. 为什么用"规则可编程"而不是每次查询都交互？ DNS Query 高频且对时延敏感（用户可感知）。若每次查询都让 SMF 实时决策，SBI 信令开销和时延都不可接受。DNS Rule 把决策逻辑预编译到 EASDF，使其能在数据面就近执行匹配与转发，只在需要 SMF 介入（DQI/DAI）时才回调——这是典型的"控制面下发策略、数据面快速执行"的分层设计。

3. 为什么需要 EAS IP range？ DNS Answer 经常包含多个 A 记录（CDN 多节点、监控、备用），但 SMF 只关心真正的边缘 EAS。range 过滤掉了无关 IP，避免误触发 PSA 重选和分流抖动。

4. 为什么强调"UE 必须用 EASDF 作为 DNS server"？ 这是整个机制的前提假设。如果 UE 用硬编码的 8.8.8.8 或 DNS-over-HTTPS（DoH）直连外部 resolver，流量完全不经过 EASDF，机制彻底失效。这也是 Rel-17 起运营商必须在 UE 签约/网络侧强约束 DNS server 配置的根本原因。

八、抓包识别与常见故障排查

抓包识别要点

• UE↔UPF↔EASDF：UDP 目的端口 53 的标准 DNS。关键看 Query Name（FQDN）是否为边缘应用域名。
• SMF↔EASDF（SBI）：HTTP/2 over TLS，URI 前缀 /naeasdf-dns-contexts 或 /eeasdf-dns-contexts（前缀因规范版本/厂商而异），方法为 POST/PUT/DELETE；回调方向是 EASDF→SMF 的 POST 携带 dnsQueryInfo / dnsAnswerInfo。
• N4（SMF↔UPF）：PFCP 消息，关注新增的 PDR（Source Interface = CORE/ACCESS, PDI 中 FQDN 或 Application ID 检测）和分流 FAR。

常见故障点

Q1: EASDF 和普通 DNS resolver 的本质区别是什么？ A: 普通 DNS resolver 对网络完全"无状态"，只做域名→IP 的映射。EASDF 是被 SMF 编程、状态与会话绑定的 resolver——它的解析/转发/上报行为由 DNS Rule 动态决定，并且会把 DNS 交互的关键信息（DQI/DAI）回传给 5GC 控制面，从而驱动流量重定向。它是"看得见 5GC、也被 5GC 看见"的 DNS。

Q2: 如果 UE 用 DNS-over-HTTPS 绕过 EASDF，机制还成立吗？ A: 不成立。DoH/DoT 把 DNS 流量加密并直连外部 resolver，UPF 的 N4 检测规则（基于 UDP/53）无法识别，EASDF 收不到任何 Query。Rel-17 的 EASDF 设计假设 UE 走明文 DNS 到 EASDF。这也是为什么运营商需在签约/网络侧约束 UE 的 DNS server 配置。对 DoH 的应对是 Rel-18/19 持续讨论的开放议题。

Q3: DQI 和 DAI 必须同时上报吗？能否只用一个？ A: 可灵活组合，这正是 DNS Rule 的设计目的。最简化部署可只用 REPORT_DNS_ANSWER（DAI），SMF 拿到 IP 即可决策；追求低重定向时延的部署可叠加 REPORT_DNS_QUERY（DQI）让 SMF 提前预选 PSA。两者并非强制同时使用。

Q4: One-Time DNS Rule 解决什么问题？ A: 它匹配一次后自动失效（状态转 Expired），常用于 UE 移动后的 EAS rediscovery——只触发一次重新发现，避免对同一个应用反复上报、反复切换 PSA 造成业务抖动。

Q5: EASDF 与 UL CL 是什么关系？ A: 二者分工不同但协同。EASDF 负责"发现"（帮 UE 拿到就近 EAS 的 IP）；UL CL/本地 PSA 负责"分流"（把去往该 EAS IP 的流量路由到边缘）。EASDF 通过 DAI 把 EAS IP 告诉 SMF，SMF 据此插入 UL CL。没有 EASDF，SMF 不知道该往哪个边缘分流；没有 UL CL，即使知道了也分流不出去。

参考来源

1. 3GPP TS 23.548 — 5G System Enhancements for Edge Computing — clause 6.2.3.2.2 EAS Discovery Procedure with EASDF、clause 6.2.3.4 EAS Deployment Information
2. 3GPP — Edge computing in CT protocols — 官方对 EASDF DNS 消息匹配与上报机制的概述
3. TS 29.556 — Neasdf Services (Stage 3) — DNS Context / DNS Rule 的 SBI 接口与数据结构定义
4. CableLabs — How 3GPP Is Fostering Network Transformation for Edge Compute — EASDF 向 SMF 上报 DNS 消息副本用于数据网络选择的工程解读
5. IEEE Xplore — On Using the EASDF to Enforce Edge Selection — 对 EASDF 边缘选择机制及实现争议的学术分析

本文由「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 等场景全覆盖。