在5G边缘计算（Edge Computing, EC）体系中，UL CL（上行分类器）和DNAI（数据网络接入标识）解决了"业务流如何被分流到本地数据网络"的传输层问题——这部分在UL CL插入与DNAI重定位机制中已被详细拆解。但这只完成了管道铺设，还遗留一个更根本的问题：UE怎么知道该连哪个边缘应用服务器（EAS）的IP地址？
传统DNS机制面临三重困境：
为打破这三重困境，3GPP在Release 17引入了一个全新的核心网网元——EASDF（Edge Application Server Discovery Function，边缘应用服务器发现功能），定义于 TS 23.548《面向边缘计算的5G系统增强；Stage 2》 与 TS 29.556《边缘应用服务器发现服务》。EASDF的本质是：一个可以被5GC"编程"的DNS解析器——SMF通过服务化接口向它下发DNS消息处理规则（DNS message handling rule），使其具备FQDN匹配、DNS上报、EAS IP替换、定向转发等"可控DNS"能力，从而让5GC首次掌握了DNS这一应用层命脉。
设计哲学：UL CL是"修路"，EASDF是"指路"。两者协同才能构成完整的边缘计算使能闭环。Release 19进一步增强了EAS发现/重发现与UPF重选，降低对中心5GC NF的冲击。
graph TD
UE[UE<br/>含EDC边缘DNS客户端] -->|DNS Query/Response| EASDF[EASDF<br/>可编程DNS解析器]
AF[AF<br/>应用功能] -->|EAS部署信息| NEF[NEF]
NEF -->|存储| UDR[UDR]
SMF[SMF] -->|Neasdf_BaselineDNSPattern<br/>Neasdf_DNSContext| EASDF
EASDF -->|Neasdf_DNSContext_Notify<br/>DNS消息上报| SMF
SMF -.查询EAS部署信息.-> UDR
SMF -->|N4 规则| UPF[UPF<br/>UL CL + 本地PSA]
UPF -->|N6| EAS[EAS<br/>边缘应用服务器]
UE -->|用户面| UPF
style EASDF fill:#e1f5ff,stroke:#0277bd
style SMF fill:#fff3e0,stroke:#e65100
角色速览：
| 网元 | 规范定位 | 核心职责 |
|---|---|---|
| EASDF | TS 23.548 §5；TS 29.556 | 接收UE DNS查询，按SMF下发的规则执行匹配/上报/替换/转发 |
| SMF | TS 23.548 §6.2.3.2.2 | 决策EASDF，下发DNS规则，根据上报选择EAS与DNAI，触发UL CL |
| AF | TS 23.548 §6.2.3.4 | 提供EAS部署信息（FQDN、DNAI、EAS IP范围） |
| EDC（UE侧） | TS 23.548 §6.2.4 / Annex C | 保证EAS相关DNS请求发往5GC指定的EASDF/解析器 |
TS 23.548 §4定义了两类边缘连接模型，EASDF在两者中的工作方式略有不同：
本文聚焦于SBO模型下的EAS发现流程（§6.2.3.2.2 with EASDF），这是最主流、信令最完整的路径。
下图严格依据 TS 23.548 §6.2.3.2.2 与 §6.2.3.4 的流程描述绘制，分为四个阶段：
sequenceDiagram
autonumber
participant AF
participant NEF
participant UDR
participant SMF
participant EASDF
participant UE
participant UPF as UPF(ULCL+PSA)
participant EAS
rect rgb(245,250,255)
Note over AF,UDR: 阶段0 — EAS部署信息预配置(§6.2.3.4)
AF->>NEF: Nnef_EASDeployment Create<br/>(FQDN模式, DNAI, EAS IP范围)
NEF->>UDR: Nudr_DataRepository<br/>(存储EAS Deployment Info)
end
rect rgb(255,248,240)
Note over SMF,UE: 阶段1 — PDU会话建立 & EASDF配置
UE->>SMF: PDU Session Establishment Request<br/>(DNN, S-NSSAI)
SMF->>UDR: 查询EAS Deployment Info
SMF->>EASDF: Neasdf_BaselineDNSPattern_Create<br/>(FQDN范围数组, EAS IP范围数组)
SMF->>EASDF: Neasdf_DNSContext_Create<br/>(DNS handling rule, DNN, S-NSSAI, pduSessionId)
SMF-->>UE: PDU Session Est. Accept<br/>(PCO携带 EASDF IP 作为DNS server)
end
rect rgb(240,255,240)
Note over UE,EASDF: 阶段2 — EAS发现(DNS查询与上报)
UE->>EASDF: DNS Query (FQDN = eas.edge.com)
EASDF->>EASDF: 匹配 Baseline DNS message<br/>detection template
EASDF->>SMF: Neasdf_DNSContext_Notify<br/>(DNS message report: FQDN/源IP)
end
rect rgb(255,240,245)
Note over SMF,EAS: 阶段3/4 — SMF决策 & EAS IP替换/接入
SMF->>SMF: 依据UE位置+EC拓扑<br/>选择目标EAS与DNAI
SMF->>UPF: N4会话(插入UL CL + 本地PSA)
SMF->>EASDF: Neasdf_DNSContext_Update<br/>(EAS IP替换对 或 转发Local DNS地址)
EASDF->>EASDF: 执行EAS IP地址替换
EASDF-->>UE: DNS Response(本地EAS IP)
UE->>EAS: 经本地PSA低时延路径接入
end
阶段0——EAS部署信息预配置（§6.2.3.4）
AF通过Nnef_EASDeployment服务将"EAS部署信息"提交给NEF，NEF存入UDR。该信息是与具体UE无关的全局数据，可按DNN、S-NSSAI、内部组标识（Internal Group Identifier）维度划分。它包含FQDN范围、DNAI、EAS IP地址范围等，是后续EASDF规则生成的"原料"。
阶段1——PDU会话建立与EASDF配置
SMF在PDU会话建立过程中执行EASDF选择（依据DNN、S-NSSAI、DNAI），随后通过两条关键服务化消息配置EASDF：
- Neasdf_BaselineDNSPattern_Create：下发"基线DNS模式"——由FQDN范围数组、EAS IP范围数组构成的检测模板与处理动作，同样与UE会话无强绑定。
- Neasdf_DNSContext_Create：为该PDU会话创建DNS上下文，绑定pduSessionId、DNN、S-NSSAI与具体的DNS消息处理规则。
随后SMF在PDU Session Establishment Accept的PCO（协议配置选项）中把EASDF的IP地址作为DNS服务器地址下发给UE。UE的EDC（Edge DNS Client）据此保证后续EAS相关DNS查询发往EASDF而非公网。
阶段2——DNS查询与上报（核心创新点）
UE发起标准DNS查询（如解析eas.edge.com）。EASDF收到后，用阶段1下发的检测模板做匹配。命中则触发Neasdf_DNSContext_Notify，将DNS消息内容（FQDN、查询类型、源IP等）上报给SMF——这是5GC首次能"看见"应用层DNS意图的瞬间。
阶段3——SMF决策与UPF重配
SMF依据UE当前位置、EC拓扑、EAS负载，选定目标EAS及其DNAI，执行：①N4会话更新以插入UL CL与本地PSA；②向EASDF下发Neasdf_DNSContext_Update，指示处理动作。
阶段4——EAS IP替换与接入 EASDF按更新后的规则执行EAS IP地址替换（将公网解析得到的中心EAS IP替换为本地EAS IP），或转发到SMF指定的Local DNS。最终DNS响应返回UE，UE用本地EAS IP发起应用连接，流量经本地PSA直达边缘——闭环完成。
DNS消息处理规则是EASDF的"大脑"，其结构如下：
graph TD
Ctx[Neasdf_DNSContext]:::ctx
Ctx --> P1[pduSessionId]
Ctx --> P2[dnn]
Ctx --> P3[snssai]
Ctx --> P4[ueIpv4Addr / ueIpv6Prefix]
Ctx --> P5[dnsMessageHandlingRule]:::rule
Ctx --> P6[baselineDnsPatternId]
P5 --> D1[dnsMessageDetectionTemplate]:::det
P5 --> D2[dnsMessageHandlingActions]:::act
D1 --> D1a[域名信息<br/>FQDN范围数组]
D1 --> D1b[EAS IP地址范围数组]
D2 --> A1[上报触发条件<br/>hit/miss]
D2 --> A2[EAS IP地址替换对<br/>源IP → 目标IP]
D2 --> A3[转发目标<br/>Local DNS地址]
D2 --> A4[规则生命周期<br/>One-Time / Persistent]
classDef ctx fill:#e1f5ff,stroke:#0277bd;
classDef rule fill:#fff3e0,stroke:#e65100;
classDef det fill:#f3e5f5,stroke:#6a1b9a;
classDef act fill:#e8f5e9,stroke:#2e7d32;
| IE名称 | 所在服务/消息 | 含义 | 工程意义 |
|---|---|---|---|
pduSessionId |
DNSContext | PDU会话标识 | EASDF按会话隔离规则，支撑多会话并发 |
dnsMessageDetectionTemplate |
DNSContext | FQDN范围+EAS IP范围 | 决定哪些DNS查询需要"被5GC介入" |
baselineDnsPatternId |
BaselineDNSPattern | 基线模式引用ID | 支持规则复用，降低信令开销 |
dnsMessageHandlingActions |
DNSContext | 替换/转发/上报动作集 | EASDF行为的"指令集" |
EAS IP address replacement |
handlingActions | 源EAS IP→目标EAS IP对 | 实现DNS结果本地化的关键 |
dnsServerIpAddress |
DNSContext / Notify | Local DNS转发地址 | 供EASDF进一步解析 |
trigger（in DNS message report） |
DNSContext_Notify | hit/miss指示 | 区分命中模板与否的上报策略 |
EASDF对每条DNS查询的处理遵循如下状态机，理解它有助于排错：
stateDiagram-v2
[*] --> Configured: SMF下发DNSContext规则
Configured --> Matching: 收到UE DNS Query
Matching --> Reporting: FQDN/IP命中检测模板
Matching --> Forwarding: 未命中 → 直接转发公网
Reporting --> WaitingSMF: Notify SMF(DNS message report)
WaitingSMF --> Replacing: SMF指示EAS IP替换
WaitingSMF --> Forwarding: SMF指示转发Local DNS
WaitingSMF --> Rejecting: SMF指示丢弃/不响应
Replacing --> Responding: 返回替换后本地EAS IP
Forwarding --> Responding: 返回Local DNS解析结果
Responding --> [*]
Rejecting --> [*]
One-Time vs Persistent规则：dnsMessageHandlingActions可标记为一次性（One-Time，仅作用于首条匹配查询）或持久（Persistent）。One-Time规则常用于首次EAS发现后即清除，避免后续UE重连时重复触发SMF决策，降低中心NF信令压力——这是Release 19优化的重点之一。
TS 23.548提供了三种EAS发现路径，工程选型需权衡：
| 维度 | EASDF（§6.2.3.2.2） | Local DNS Server（§6.2.3.2.3） | Distributed Anchor（§6.2.2） |
|---|---|---|---|
| 解析主体 | EASDF（5GC内网元） | 外部Local DNS解析器 | 各PDU会话独立DNS |
| 5GC可见性 | 高（SMF全量感知） | 中（仅SMF选DNAI，不感知DNS内容） | 低 |
| EAS IP替换 | 原生支持 | 不支持 | 不支持 |
| UL CL触发时机 | DNS查询阶段即可决策 | 需先插入UL CL再选Local DNS | 会话建立时即锚定 |
| 跨厂商/跨域 | 需5GC支持EASDF | 依赖外部DNS基础设施 | 最简单 |
| 典型部署 | 运营商自营MEC平台 | 与第三方DNS协同 | 简单园区/专网 |
| 信令复杂度 | 高 | 中 | 低 |
选型建议：运营商自营、需精细流量调度与EAS重定位的场景优先EASDF；与现有DNS体系深度耦合或专网场景可考虑Local DNS方案。
在NG接口与N6接口联合抓包，EAS发现呈现"DNS两次往返+应用连接"特征：
| 故障现象 | 根因 | 排错思路 |
|---|---|---|
| UE始终连到中心EAS，无边缘分流 | PCO未下发EASDF IP，EDC回退公网DNS | 检查PDU Session Est. Accept PCO内容；核查UE是否实现EDC（Annex C） |
| EASDF未上报Notify | 检测模板FQDN范围与查询不匹配 | 核对dnsMessageDetectionTemplate的FQDN范围；AF提交的EAS部署信息是否覆盖该FQDN |
| UL CL已插入但DNS响应仍为中心IP | EAS IP替换对配置缺失或源IP不匹配 |
检查Neasdf_DNSContext_Update中替换对；确认公网解析IP与配置源IP一致 |
| UE移动后仍连旧EAS | 未触发EAS Re-discovery（§6.2.3.3） | 核查SSC模式与Edge Relocation配置；DNAI变更是否驱动重发现 |
| ## 九、Release演进趋势 |
Q1: EASDF和普通DNS服务器到底有什么区别？ A: 普通DNS只做"FQDN→IP"的无状态映射，对5GC完全透明。EASDF是5GC可编程的DNS解析器：SMF通过服务化接口（TS 29.556）下发检测模板与处理动作，使其具备DNS内容上报、EAS IP替换、定向转发能力，从而把DNS这一应用层决策权收归5GC，实现"DNS驱动UPF"。
Q2: UE怎么知道要把DNS发给EASDF？ A: 通过PDU会话建立时SMF在PCO中下发的DNS服务器地址，结合UE侧EDC（Edge DNS Client）功能（TS 23.548 §6.2.4/Annex C）。EDC确保EAS相关DNS查询发往5GC指定的EASDF/解析器，而非终端默认DNS。
Q3: EAS IP替换和UL CL插入谁先谁后？ A: 在EASDF方案中，DNS查询阶段（阶段2）SMF即获知UE意图，随后可先插入UL CL再回EAS IP替换结果（阶段3→4），也可并行。相比Local DNS方案必须先插UL CL才能选本地解析器，EASDF实现了"意图驱动"的更优时序。
Q4: EASDF方案必须依赖AF提供EAS部署信息吗？ A: 不强制。SMF可从NEF/UDR获取AF提供的EAS Deployment Information，也可使用本地预配置信息（§6.2.3.2.2）。但AF提供的信息能实现更精细的FQDN/DNAI映射与动态更新。
Q5: UE移动到新边缘节点时，EASDF如何触发重发现？ A: 通过Edge Relocation（§6.3）与EAS Re-discovery（§6.2.3.3）。SMF检测到UE位置/DNAI变化后，更新EASDF的DNS规则（如新的EAS IP替换对），并视SSC模式触发会话重建或UL CL重定位，引导UE重新解析获得本地EAS IP。
本文由「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 等场景全覆盖。