首页 › slicing-mec › 5G EASDF三模式DNS规则与EAS发现信令拆解

5G EASDF三模式DNS规则注入与EAS发现信令拆解

1 引言：为什么需要EASDF

5G边缘计算的核心挑战之一是：UE如何发现离自己物理位置最近的Edge Application Server（EAS）？在传统架构中，UE发出DNS查询，由公共DNS服务器解析，返回的往往是中心化部署的应用服务器IP地址，导致流量迂回、时延增大。

3GPP从Release 17开始在TS 23.548中引入了EASDF（Edge Application Server Discovery Function）这一全新NF，作为5G Core对DNS查询进行"智能化干预"的关键网元。EASDF本质上是一个受SMF控制的DNS代理/解析器：SMF向其注入DNS消息处理规则（DNS Message Handling Rules），EASDF根据这些规则对UE的DNS查询进行拦截、上报、转发或直接应答，从而将UE引导至最优的边缘应用服务器。

本文将基于TS 23.548 V18.7.0 Section 6.2.3.2.2和TS 29.556（Nsad服务定义），深度拆解EASDF的DNS规则注入机制、三种转发模式（A/B/C）的设计博弈、以及完整的EAS发现信令时序。

2 EASDF在5GC中的架构定位

2.1 功能架构

graph TB
    UE[UE/EDC] -->|DNS Query| EASDF[EASDF]
    EASDF -->|DNS Query/Response| LDNS[Local DNS Server]
    EASDF -->|DNS Query/Response| CDNS[C-DNS<br/>Central DNS]

    SMF[SMF] -->|Nsad_Create<br/>Nsad_Update| EASDF
    EASDF -->|Nsad_Notify| SMF

    SMF -->|N4| UPF_C[C-PSA UPF]
    SMF -->|N4| UPF_L[L-PSA UPF<br/>+UL CL]

    AF[AF] -->|EAS Deployment Info| NEF[NEF]
    NEF -->|Nudr| UDR[UDR]
    SMF -->|Retrieve EAS Deploy Info| NEF

    UE -->|Data Traffic| UPF_C
    UE -->|Data Traffic| UPF_L
    UPF_L -->|N6| EAS[EAS]
    UPF_C -->|N6| APP[Central App Server]

    style EASDF fill:#e1f5fe
    style SMF fill:#fff3e0
    style UPF_L fill:#e8f5e9

EASDF在架构中位于控制面，不处理用户面数据。其核心接口关系如下表所示：

接口	协议	服务操作	用途
SMF ↔ EASDF	Nsad（SBI）	Nsad_Create	创建DNS上下文，注入初始规则
SMF ↔ EASDF	Nsad（SBI）	Nsad_Update	更新/新增/删除DNS规则
EASDF → SMF	Nsad（SBI）	Nsad_Notify	上报DNS查询内容（Reporting Action）
UE ↔ EASDF	DNS over PDU Session	标准DNS协议	UE发送DNS查询，接收DNS响应
EASDF ↔ DNS Server	DNS	标准DNS协议	转发DNS查询到Local DNS或C-DNS

2.2 EASDF与UL CL/BP的协作关系

EASDF与UL CL（Uplink Classifier）/BP（Branching Point）是5G边缘计算的两大核心机制，二者紧密协作：

EASDF负责"发现"——决定UE应该连接哪个EAS的IP地址
UL CL/BP负责"引流"——将UE到EAS的流量通过L-PSA（本地PDU会话锚点）转发到边缘DN

两者之间的触发关系是：EASDF上报DNS查询内容给SMF → SMF根据DNAI信息插入UL CL/BP和L-PSA → 用户面流量被引导到边缘。

3 DNS消息处理规则的完整结构

3.1 规则层级：BaselineDNSPattern与DNS Message Handling Rule

TS 23.548定义了两层规则结构，这是EASDF设计的精妙之处：

graph TD
    subgraph "预配置层（跨PDU Session共享）"
        BDP[BaselineDNSPattern]
        BDT[Baseline DNS Message<br/>Detection Template]
        BHA[Baseline DNS Handling<br/>Actions Information]
        BDP --> BDT
        BDP --> BHA
    end

    subgraph "会话层（每PDU Session独立）"
        DMHR[DNS Message Handling Rule]
        DET[DNS Message<br/>Detection Template]
        ACT[Action]
        DMHR --> DET
        DMHR --> ACT
        ACT --> RA[Reporting Action]
        ACT --> FA[Forwarding Action<br/>Mode A/B/C]
        ACT --> CA[Control Action]
    end

    BDT -.->|引用| DET
    BHA -.->|引用| FA

    style BDP fill:#fce4ec
    style DMHR fill:#e3f2fd

设计意图：BaselineDNSPattern由AF提供的EAS部署信息（EAS Deployment Information）生成，不绑定特定PDU Session，可被多个PDU Session共享。当SMF为某个PDU Session创建DNS规则时，可以通过引用BaselineDNSPattern ID来复用预配置的检测模板和动作信息，大幅减少信令开销。

3.2 DNS Message Handling Rule详细IE

根据TS 23.548 Section 6.2.3.2.2，每条DNS规则包含以下IE：

IE名称	必选/可选	说明
Precedence	必选	规则优先级，数值越小优先级越高
DNS Message Handling Rule Identity	必选	规则唯一标识符
Baseline DNS message detection template ID	可选	引用预配置的检测模板
DNS message detection template	可选	本地定义的检测条件
— DNS message type	条件必选	DNS Query 或 DNS Response
— Source IP address	可选	UE IP地址（Query时）
— Array of FQDN ranges	可选	匹配的FQDN范围
— Array of EAS IP address ranges	可选	匹配的EAS IP范围（Response时）
DNS message Identifier	可选	用于Notify与Update的关联
Action(s)	必选（至少一个）	见下文三种动作详解

3.3 三类Action深度解析

Reporting Action（上报动作）

当DNS消息匹配检测模板时，EASDF将DNS消息内容上报给SMF。上报内容包括： - 目标FQDN - DNS Server返回的IP地址信息（如有） - Reporting-once指示：仅上报首次匹配，用于触发UL CL/BP插入

关键设计：Reporting-once机制避免了对同一FQDN的重复上报。一旦EASDF上报了某个EAS IP地址对应的DNS查询，SMF触发UL CL/BP插入后，后续同一FQDN的DNS查询不再需要上报——因为流量已经通过L-PSA分流到边缘。

Forwarding Action（转发动作）——三模式博弈

这是EASDF最核心的动作，TS 23.548定义了三种互斥的转发模式：

模式	DNS消息去向	关键IE	适用场景
Mode A	转发到DNS服务器，携带EDNS Client Subnet选项	ECS option构建信息	需要DNS服务器基于UE位置返回最近EAS
Mode B	转发到指定DNS服务器	DNS Server Address	SMF已知最优DNS服务器（如Local DNS）
Mode C	不转发，EASDF直接构造DNS Response	EAS IP address	SMF已知目标EAS IP，无需DNS解析

Mode A详解：EASDF在转发DNS查询时，将SMF提供的EDNS Client Subnet（ECS）选项嵌入或替换DNS查询中的ECS字段。DNS服务器根据ECS中的UE位置信息，返回地理位置最近的EAS IP地址。这种模式利用了标准DNS协议的扩展机制（RFC 7871），对UE完全透明。

Mode B详解：SMF直接指定DNS查询应转发到的目标DNS服务器地址。典型场景是SMF已知某个Local DNS Server（位于边缘DN内部），该DNS Server拥有本地EAS的完整解析信息。如果SMF未指定DNS Server Address，EASDF使用本地预配置的默认DNS服务器。

Mode C详解：SMF直接提供EAS的IP地址，EASDF构造DNS Response返回给UE。这是最直接的模式，完全绕过了DNS解析过程。适用于SMF已从EAS部署信息或AF Influence获知目标EAS IP地址的场景。延迟最低，但灵活性最差。

Control Action（控制动作）

提供对DNS消息流的精细控制： - Buffer：缓存DNS消息（用于等待SMF决策） - Send buffered DNS Response：释放缓存的响应 - Discard cached DNS Response：丢弃缓存 - Construct DNS Query：主动构造DNS查询

4 EAS发现完整信令时序

4.1 信令流程全景图

基于TS 23.548 Section 6.2.3.2.2和TS 23.502 Section 4.3.5.1，完整的EAS发现流程如下：

sequenceDiagram
    participant UE as UE/EDC
    participant RAN as (R)AN
    participant AMF as AMF
    participant SMF as SMF
    participant EASDF as EASDF
    participant NEF as NEF/UDR
    participant PCF as PCF
    participant UPF_C as C-PSA UPF
    participant UPF_L as L-PSA UPF
    participant LDNS as Local DNS
    participant EAS as EAS

    Note over UE,EAS: 阶段一：PDU Session建立与EASDF配置
    UE->>RAN: PDU Session Establishment Request
    RAN->>AMF: N2 SM Request (PDU Session ID, DNN, S-NSSAI)
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext Request

    SMF->>PCF: Npcf_SMPolicyControl_Create (获取PCC规则)
    PCF-->>SMF: PCC Rules (含AF Influence/URLLC需求)

    SMF->>NEF: Nnef_EASDeployment_Get (获取EAS部署信息)
    NEF-->>SMF: EAS Deployment Info (FQDN-DNAI映射)

    SMF->>EASDF: Nsad_DNSContext_Create<br/>(UE IP, BaselineDNSPattern)
    EASDF-->>SMF: Nsad_DNSContext_Create Response (DNS Context ID)

    SMF->>UPF_C: N4 Session Establishment (C-PSA)
    UPF_C-->>SMF: N4 Response

    SMF-->>AMF: N1N2 Message Transfer<br/>(EASDF IP as DNS Server, via PCO)
    AMF->>RAN: N2 SM Response (PDU Session Resource Setup)
    RAN-->>UE: PDU Session Establishment Accept<br/>(PCO: DNS Server = EASDF IP)

    Note over UE,EAS: 阶段二：UE发起DNS查询触发EAS发现
    UE->>EASDF: DNS Query (FQDN: app.example.com)

    EASDF->>EASDF: 匹配DNS Handling Rule<br/>触发Reporting Action
    EASDF->>SMF: Nsad_DNSContext_Notify<br/>(Target FQDN, DNS Msg ID)

    SMF->>SMF: 确定DNAI → 选择L-PSA位置

    SMF->>UPF_L: N4 Session Establishment (L-PSA)
    UPF_L-->>SMF: N4 Response
    SMF->>UPF_C: N4 Session Modification<br/>(插入UL CL/BP规则)
    UPF_C-->>SMF: N4 Response

    SMF->>EASDF: Nsad_DNSContext_Update<br/>(新增Forwarding Action Mode B:<br/>Target = Local DNS Server)

    Note over UE,EAS: 阶段三：DNS解析与EAS连接
    EASDF->>LDNS: DNS Query (app.example.com)<br/>(转发到Local DNS)
    LDNS-->>EASDF: DNS Response (EAS IP: 10.1.2.3)
    EASDF-->>UE: DNS Response (EAS IP: 10.1.2.3)

    UE->>UPF_C: Data Packet (Dst: 10.1.2.3)
    UPF_C->>UPF_L: UL CL分流 (匹配EAS IP)
    UPF_L->>EAS: Data Packet → Edge Application

4.2 逐步信令解析

步骤1-4：PDU Session建立与EAS部署信息获取

当UE发起PDU Session建立请求时，AMF选择SMF。SMF执行以下关键动作：

向PCF获取PCC规则：通过Npcf_SMPolicyControl_Create服务，获取包含AF Influence信息的PCC规则。AF可能通过NEF/PCF指示特定应用的流量应被路由到边缘DN。
向NEF获取EAS部署信息：SMF通过Nnef_EASDeployment信息检索（如TS 23.548 Section 6.2.3.4定义），获取AF上报的EAS部署信息。该信息包含FQDN与DNAI的映射关系，以及各DNAI对应的EAS IP地址范围。这些信息用于构建BaselineDNSPattern。
选择EASDF并创建DNS上下文：SMF根据DNN、S-NSSAI和UE位置选择一个EASDF实例，通过Nsad_DNSContext_Create消息创建DNS上下文。

Nsad_DNSContext_Create的关键IE结构：

IE	说明
UE IP Address	PDU Session中分配给UE的IP地址
DNS Context ID	EASDF分配的上下文标识
BaselineDNSPattern	预配置的DNS检测模板和动作信息
DNS Message Handling Rules	初始DNS规则集

步骤5-8：EASDF地址下发给UE

SMF将EASDF的IP地址通过PCO（Protocol Configuration Options） IE传递给UE。UE将其配置为该PDU Session的DNS服务器地址。这意味着UE后续所有DNS查询都会发往EASDF而非公共DNS。

这一设计的精妙之处在于：对UE应用层完全透明。UE上的应用程序仍然使用标准DNS API（如getaddrinfo()），无需感知边缘计算的存在。

步骤9-10：DNS查询与Reporting Action触发

UE发起DNS查询（如解析app.example.com），查询消息通过PDU Session到达EASDF。EASDF执行规则匹配：

遍历DNS Message Handling Rules，按Precedence排序
找到匹配FQDN范围的规则
该规则包含Reporting Action（可能带Reporting-once指示）
EASDF通过Nsad_DNSContext_Notify上报DNS查询内容给SMF

Notify消息中的关键信息： - Target FQDN：UE请求解析的域名 - DNS Message Identifier：用于后续Update消息与此Notify的关联 - Source IP：UE IP地址（用于SMF确认PDU Session）

步骤11-14：SMF决策与UL CL/BP插入

SMF收到Notify后执行核心决策逻辑：

DNAI确定：根据FQDN和UE当前位置，确定最优DNAI
L-PSA选择：选择靠近目标DNAI的UPF作为L-PSA
UL CL/BP插入：在C-PSA上配置UL CL规则，将目标EAS IP的流量分流到L-PSA
更新EASDF规则：通过Nsad_DNSContext_Update向EASDF下发新的Forwarding Action

步骤15-17：DNS解析完成与EAS连接

更新后的规则指示EASDF将DNS查询转发到Local DNS Server（Mode B）。Local DNS返回EAS IP地址。EASDF将DNS Response转发给UE。

UE获得EAS IP地址后，向该IP发送数据包。数据包经过C-PSA时，UL CL规则匹配目标IP，将流量分流到L-PSA，最终到达边缘DN中的EAS。

5 三种EAS发现过程对比

TS 23.548 Section 6.2.3.2定义了多种EAS发现方式：

维度	过程A（EASDF + DNS查询处理）	过程B（Local DNS Server）	过程C（DNS Server选择辅助）
DNS Server	EASDF	Local DNS Server	EASDF
DNS解析主体	EASDF根据SMF规则处理	Local DNS直接解析	EASDF转发到指定DNS
SMF干预程度	高（逐条规则控制）	低（仅选择DNS Server）	中（选择DNS Server）
UL CL触发方式	EASDF上报→SMF决策	SMF预判断	EASDF上报→SMF决策
DNS响应延迟	较高（Notify-Update往返）	最低	中等
适用场景	动态EAS部署、按需分流	静态部署、已知EAS位置	混合场景

5.1 三模式状态转换

stateDiagram-v2
    [*] --> PDU_Session_Established: PDU Session建立完成
    PDU_Session_Established --> DNS_Query_Received: UE发送DNS查询
    DNS_Query_Received --> Rule_Matching: EASDF执行规则匹配

    Rule_Matching --> Reporting: 匹配Reporting Action
    Rule_Matching --> Forwarding_A: 匹配Mode A
    Rule_Matching --> Forwarding_B: 匹配Mode B
    Rule_Matching --> Forwarding_C: 匹配Mode C
    Rule_Matching --> Default_Forward: 无匹配规则

    Reporting --> SMF_Decision: Nsad_Notify
    SMF_Decision --> ULCL_Insert: SMF确定DNAI
    SMF_Decision --> Rule_Update: Nsad_Update

    ULCL_Insert --> Rule_Update: L-PSA就绪
    Rule_Update --> Forwarding_B: 更新为Mode B
    Rule_Update --> Forwarding_C: 更新为Mode C

    Forwarding_A --> DNS_Response: DNS Server返回
    Forwarding_B --> DNS_Response: Local DNS返回
    Forwarding_C --> DNS_Response: EASDF构造响应
    Default_Forward --> DNS_Response: C-DNS返回

    DNS_Response --> UE_Connected: UE获得EAS IP
    UE_Connected --> EAS_Redirection: UE移动触发DNAI变化
    EAS_Redirection --> Rule_Update: SMF触发EAS重发现

    UE_Connected --> [*]: PDU Session释放

6 Nsad服务接口详解（TS 29.556）

6.1 Nsad_DNSContext_Create

SMF使用此服务操作创建DNS上下文并注入初始规则。

请求消息关键IE：

IE	类型	说明
supi	Supi	订阅永久标识符
dnn	Dnn	数据网络名称
snssai	Snssai	网络切片标识
ueIpv4Address / ueIpv6Prefix	IP Address	UE IP地址
dnsServerIpAddress	IpAddress	EASDF自身的DNS服务器地址
dnsMessageHandlingRules	array	DNS消息处理规则列表
baselineDnsPatterns	array	基线DNS模式列表

响应消息：返回DNS Context ID，后续所有操作通过此ID关联。

6.2 Nsad_DNSContext_Update

SMF使用此操作更新EASDF上的DNS规则。支持以下操作： - 新增DNS Message Handling Rule - 修改现有规则（通过Rule Identity定位） - 删除规则 - 下发Buffer/Release等Control Action

关键场景： - SMF收到EASDF的Notify后，下发Forwarding Action（Mode B/C）规则 - UE移动触发DNAI变化时，SMF更新Forwarding目标 - AF更新EAS部署信息后，SMF更新BaselineDNSPattern

6.3 Nsad_DNSContext_Notify

EASDF主动向SMF上报DNS消息内容。触发条件是规则中的Reporting Action。

Notify消息IE：

IE	说明
dnsContextId	关联的DNS上下文
dnsMessageIdentifier	DNS消息标识（用于与Update关联）
targetFqdn	UE请求解析的FQDN
resolvedIpAddress	DNS解析返回的IP（如已有）
dnsMessageType	Query 或 Response

6.4 Nsad服务交互时序

sequenceDiagram
    participant SMF
    participant EASDF

    Note over SMF,EASDF: DNS上下文生命周期

    SMF->>EASDF: Nsad_DNSContext_Create<br/>(规则集: Reporting+Forwarding)
    EASDF-->>SMF: 201 Created (DNS Context ID)

    Note over EASDF: UE DNS查询到达...

    EASDF->>SMF: Nsad_DNSContext_Notify<br/>(FQDN, DNS Msg ID)

    SMF->>SMF: 决策: 插入UL CL, 选择L-PSA

    SMF->>EASDF: Nsad_DNSContext_Update<br/>(新增 Forwarding Mode B:<br/>Target DNS = Local DNS)
    EASDF-->>SMF: 200 OK

    Note over EASDF: DNS解析完成, 响应UE

    Note over SMF,EASDF: UE移动场景...

    SMF->>EASDF: Nsad_DNSContext_Update<br/>(更新Forwarding目标,<br/>Reporting-once reset)
    EASDF-->>SMF: 200 OK

    EASDF->>SMF: Nsad_DNSContext_Notify<br/>(新FQDN查询触发重发现)

    SMF->>EASDF: Nsad_DNSContext_Update<br/>(Forwarding Mode B:<br/>Target DNS = New Local DNS)

    Note over SMF,EASDF: PDU Session释放

    SMF->>EASDF: Nsad_DNSContext_Delete
    EASDF-->>SMF: 204 No Content

7 EAS重发现与边缘重定位

7.1 DNAI变化触发EAS重发现

当UE移动导致最优DNAI发生变化时，SMF需要触发EAS重发现。根据TS 23.548 Section 6.2.3.3，流程如下：

SMF检测DNAI变化：通过N2切换、Xn切换或UE位置报告触发
重置Reporting-once指示：通过Nsad_Update将之前的Reporting-once规则复位
EASDF再次上报：UE后续DNS查询触发新的Reporting Action
SMF重新决策：选择新的L-PSA，更新UL CL/BP分流规则
更新Forwarding Action：指向新的Local DNS Server

7.2 Reporting-once机制的博弈设计

Reporting-once是EASDF设计中最精巧的机制之一，体现了"触发即止"的设计哲学：

阶段	Reporting-once状态	行为
初始	设置（Set）	首次匹配的DNS查询上报SMF，后续同一规则不再上报
UL CL已插入	保持Set	无需重复上报（分流已生效）
UE移出当前DNAI	重置（Reset）	允许再次上报，触发新的UL CL插入决策
新DNAI确定	重新Set	确保不会在稳定状态下产生冗余Notify

这个设计的核心博弈在于：上报频率 vs 响应速度。频繁上报可以更快响应UE位置变化，但会增加SMF和EASDF之间的信令负载。Reporting-once在"分流稳定时不打扰"和"位置变化时及时响应"之间取得了最优平衡。

8 实战连接

8.1 抓包识别EAS发现流程

在5GC核心网抓包中识别EAS发现流程的关键点：

抓包位置	协议	过滤条件	关注字段
SMF-EASDF接口	HTTP/2 (SBI)	`http2.header.path contains "nsad"`	Nsad_Create/Update/Notify
UE-UPF接口（N3）	DNS	`dns.qry.name`	FQDN，DNS Server IP是否为EASDF
SMF-UPF接口（N4）	N4	N4 Session Establishment	UL CL Rule, DNAI
PCO字段	NAS	NAS PDU Session Est Accept	DNS Server IP = EASDF IP

关键判断：如果UE的DNS查询目的IP是5GC网元地址（而非公共DNS如8.8.8.8），且SMF与EASDF之间存在Nsad信令交互，则确认是EAS发现流程。

8.2 常见故障点

故障现象	可能根因	排错思路
UE DNS查询超时	EASDF未正确下发规则	检查SMF是否成功发送Nsad_Create；检查EASDF是否收到
UE获得非边缘EAS IP	Forwarding Action配置错误	确认Mode A/B/C配置；检查Local DNS Server地址
数据未分流到边缘	UL CL未插入或规则错误	检查SMF是否收到Notify；检查N4 Session中的UL CL规则
UE移动后EAS不更新	Reporting-once未重置	检查SMF是否在DNAI变化时发送Nsad_Update
DNS查询被EASDF丢弃	规则优先级冲突	检查Precedence设置；确认默认转发规则存在
## 9 Rel-18/19增强要点

9.1 Rel-18：漫游场景下的EHE支持

Release 18引入了EHE（Edge Home Environment）概念，允许漫游UE在VPLMN中通过HR-SBO（Home Routed Session Breakout）访问归属PLMN的边缘服务。关键增强：

V-SMF与H-SMF协作完成EASDF选择
支持VPLMN本地DNS Server用于EAS解析
新增V-EASDF相关过程（TS 23.548 Section 6.7.2）

9.2 Rel-19：EAS发现增强

Release 19继续增强EAS发现机制： - 减少对中心化5GC NF的影响（减轻SMF负担） - 优化UPF选择和重选机制 - 支持更高效的EAS重发现流程 - 面向AR/XR、V2X等低时延场景优化

10 常见问题

Q1: EASDF与普通DNS服务器的区别是什么？ A: EASDF是一个受控的DNS代理，不是传统意义上的DNS解析器。它不自主解析域名，而是根据SMF注入的规则决定如何处理每个DNS消息——可以上报给SMF、转发到指定DNS服务器、或直接构造响应。普通DNS服务器仅根据区域文件或递归查询返回解析结果，没有与5GC控制面的交互。

Q2: 三种Forwarding模式应该优先选择哪种？ A: 选择取决于网络部署和业务需求。Mode C延迟最低（无需DNS解析），但需要SMF已知EAS IP，适用于静态部署。Mode A最灵活（利用ECS选项让DNS Server动态选择最优EAS），但依赖DNS Server支持ECS。Mode B是折中方案，SMF指定Local DNS Server，由后者完成解析。实际部署中，初始发现阶段常用Reporting+Mode A/B组合，稳定后可切换到Mode C。

Q3: 为什么需要Reporting-once而不是持续上报？ A: 因为一次UL CL/BP插入后，该PDU Session到目标EAS的流量路径已经确定。持续上报相同FQDN的DNS查询不会带来新的决策价值，只会增加SMF-EASDF之间的信令负载。只有在DNAI变化（UE移动到新区域）时才需要重新决策，此时SMF通过Reset Reporting-once来重新启用上报。

Q4: UE如何知道DNS服务器是EASDF？ A: UE不知道也不需要知道。SMF在PDU Session建立过程中，通过PCO（Protocol Configuration Options）将EASDF的IP地址作为DNS服务器地址下发给UE。UE的TCP/IP协议栈将此地址配置为DNS resolver，应用程序透明使用。这就是为什么3GPP定义了EDC（Edge DNS Client）功能——确保UE将DNS查询发往5GC指定的DNS服务器。

Q5: EAS发现与EPS中的eICIC/DCN有什么本质区别？ A: EAS发现是应用层服务发现的5GC辅助机制，目标是让UE找到最优的应用服务器IP地址。eICIC是RAN层干扰协调技术，DCN是核心网专用核心网概念。三者在不同层面解决不同问题。EAS发现的独特价值在于：它通过DNS协议这一标准互联网机制，实现了5G网络对应用流量路由的智能控制，无需修改UE应用。

参考来源

3GPP TS 23.548 V18.7.0 — Section 6.2.3.2.2 EAS Discovery Procedure with EASDF, DNS Message Handling Rules定义
3GPP TS 29.556 V17.0.0 — Nsad服务接口定义，Nsad_Create/Update/Notify服务操作
3GPP Edge Computing in CT Protocols — 3GPP官方技术概述，EASDF架构和Rel-17/18/19演进
Carota, Boutiba et al., "On Using the Edge Application Server Discovery Function to Enforce Edge Computing in 5G Networks," IEEE ICC 2024 — EASDF实现分析，DNS规则处理性能评估
CableLabs, "How 3GPP Supports Edge Compute Transformation" — EASDF DNS规则匹配与EDC客户端功能详解

本文由「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学通信知识星球海报-扫码加入