# 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 双向交互。 ```mermaid graph LR UE[UE] -->|DNS Query UDP/53| UPF[UPF-PSA] UPF -->|N4检测转发| EASDF[EASDF] EASDF -->|上游转发| CDNS[Central/External DNS] SMF[SMF] <-->|Neasdf SBI
下发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`： | SBI 操作 | 方法 / URI | 用途 | |---------|-----------|------| | Create DNS Context | `POST /eeasdf-dns-contexts` | 建立会话级 DNS 上下文，下发初始 DNS Rule | | Update DNS Context | `PUT /.../{contextId}` | 增删改 DNS Rule、变更 EAS IP range | | Delete DNS Context | `DELETE /.../{contextId}` | PDU 会话释放 | | DNS Info Notify | callback（SMF 向 EASDF 订阅） | EASDF 上报 DQI / DAI | ## 三、核心机制：DNS Rule 结构与动作语义 EASDF 的所有"智能"都封装在 **DNS Rule** 里。SMF 在 PDU 会话生命周期内可动态增删改这些规则（TS 29.556 定义了完整的 CRUD）。一个 DNS Rule 的结构如下（数据类型定义见 TS 29.571 与 TS 29.556）： ```mermaid graph TD R["DNS Rule"] --> R1["dnsRuleId（唯一标识）"] R --> R2["dnsRulePriority（匹配优先级）"] R --> R3["dnsRuleStatus
Active / Inactive"] R --> M["Match Criteria"] M --> M1["dnsDomainName
FQDN（支持通配符）"] M --> M2["dnsQueryType
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
+ EAS IP address range"] style A5 fill:#ffd,stroke:#cc8800 ``` **关键 IE 参数说明：** | IE 名称 | 含义 | 设计意图 / 取值约束 | |---------|------|---------------------| | `dnsRuleId` | 规则唯一 ID | 用于 SMF 增量更新指定规则，避免全量重配 | | `dnsRulePriority` | 整数，值小优先级高 | 多规则匹配时的仲裁，防止策略冲突歧义 | | `dnsRuleStatus` | Active / Inactive | 支持规则"停用而不删除"，便于 UE 移动时快速切换 | | `dnsDomainName` | FQDN 模式，如 `*.mec.operator.com` | 通配符匹配一组应用，减少规则数量 | | `dnsQueryType` | A / AAAA / SRV … | 区分 IPv4/IPv6/服务发现，避免误匹配 | | Action: `FORWARD` | 携带上游 DNS 地址 | 指向运营商 DNS 或特定解析器 | | Action: `REPORT_DNS_QUERY` | 命中即上报 DQI | 让 SMF 提前知道"UE 要访问什么应用" | | Action: `REPORT_DNS_ANSWER` | 携带 EAS IP range | 解析结果 IP 落在 range 内才上报，过滤非 EAS 应答 | | One-Time DNS Rule | 匹配一次后自动失效 | 用于一次性触发场景，避免重复上报风暴 | 一个特别精妙的设计是 **`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 触发阶段、流量重定向阶段**。 ```mermaid 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
(DNS Rule#1: FORWARD→中心DNS) SMF->>EASDF: DNS Rule#2: REPORT_DNS_QUERY
(match *.mec.operator.com) SMF->>EASDF: DNS Rule#3: REPORT_DNS_ANSWER
(+ EAS IP range) SMF->>UPF: N4会话建立:DNS检测规则→转发EASDF SMF-->>UE: PDU Estab Accept
(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
(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
+ 本地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 之间的对话。** ```mermaid 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 ``` | 上报类型 | 触发时机 | 关键字段 | SMF 用途 | |---------|---------|---------|---------| | DQI | DNS Query 命中 Report 规则 | FQDN、UE IP、qType、(可选)ECS | 提前感知意图、可选预选 PSA | | DAI | DNS Answer IP 命中 EAS IP range | EAS IP（可多个）、FQDN、TTL | 精确定位目标 EAS，决定 DNAI 与分流路径 | DQI 与 DAI 配合的意义在于**双保险**：DQI 让 SMF 抢跑（提前选 PSA、准备 N4 规则），DAI 给出确定性的"最终答案"（精确到 IP）。在某些部署中，SMF 可以**只用 DAI**（省去 DQI），也可以**两者都用**（追求最低重定向时延）——这正是通过组合不同 Action 的 DNS Rule 灵活实现的。 ## 六、DNS Rule 生命周期状态机 一条 DNS Rule 在其生命周期内经历如下状态转换，理解这个状态机对排错至关重要（"为什么 SMF 改了规则 EASDF 没生效？"往往就是状态问题）： ```mermaid 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 --> [*] ``` 三类典型触发组合对应的场景： | Action 组合 | 典型场景 | 行为 | |------------|---------|------| | FORWARD + REPORT_DNS_QUERY + REPORT_DNS_ANSWER | 标准边缘发现 | 透传中心 DNS + 双上报，SMF 全程知情 | | 仅 RESOLVE_LOCALLY + REPORT_DNS_ANSWER | EASDF 本地解析（无外部 DNS） | EASDF 自己用 EDI 应答，省一跳往返 | | REPORT_DNS_QUERY（One-Time） | 一次性触发 | 命中一次即失效，避免重复上报，常用于移动后重新发现 | ## 七、设计意图深度剖析 **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。 ### 常见故障点 | 现象 | 可能根因 | 排错思路 | |------|---------|---------| | 边缘流量未本地分流，仍走中心 | DNS Rule 未生效 / EASDF 未被选为 DNS server | 抓 UE DNS Query 目的 IP 是否为 EASDF；查 SMF 是否 Create Context 成功 | | SMF 收不到 DQI/DAI | Rule#2/#3 Status=Inactive 或 Match Criteria 写错 | 核对 `dnsDomainName` 通配符、`dnsQueryType` 与实际报文一致 | | DAI 上报但 PSA 没切换 | EAS IP 未落在 range 内 / DNAI 映射缺失 | 比对 DNS Answer IP 与配置 EAS IP range；查 EDI 是否含该 DNAI | | 偶发误分流到非 EAS 节点 | range 配置过宽，包含 CDN IP | 收紧 EAS IP range | | UE 用 DoH/DoT 绕过 | 终端配置了加密 DNS | EASDF 不解析 DoH/DoT；需终端侧约束 | ## 九、常见问题 **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](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3856) — 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](https://www.3gpp.org/technologies/edge-ct-protocols) — 官方对 EASDF DNS 消息匹配与上报机制的概述 3. [TS 29.556 — Neasdf Services (Stage 3)](https://www.etsi.org/deliver/etsi_ts/129500_129599/129556/) — DNS Context / DNS Rule 的 SBI 接口与数据结构定义 4. [CableLabs — How 3GPP Is Fostering Network Transformation for Edge Compute](https://www.cablelabs.com/blog/how-3gpp-is-fostering-network-transformation-for-edge-compute) — EASDF 向 SMF 上报 DNS 消息副本用于数据网络选择的工程解读 5. [IEEE Xplore — On Using the EASDF to Enforce Edge Selection](https://ieeexplore.ieee.org/document/10623085) — 对 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 等场景全覆盖。