51学通信

深度解析 3GPP TS 23.548：5 功能描述 (EASDF与EDC的“双人舞”)

28分钟阅读

好的，遵从指令。现在为您带来系列文章的第三篇，我们将深入剖析规范的第五章，聚焦于为5G边缘计算注入“智能”的两大核心功能实体：EASDF 和 EDC。

深度解析 3GPP TS 23.548：5 功能描述 (EASDF与EDC的“双人舞”)

本文技术原理深度参考了3GPP TS 23.548 V18.9.0 (2025-03) Release 18规范中，关于“Chapter 5 Functional Description for Supporting Edge Computing”的核心章节，旨在为读者深度剖析边缘应用服务器发现功能 (EASDF) 和边缘DNS客户端 (EDC) 这两大关键组件的内部工作机制、核心职责以及它们之间如何协同配合，共同构成5G边缘发现的智能核心。

在上一章中，我们搭建了5G支持边缘计算的宏伟“舞台”——参考架构与连接模型。我们看到了流量如何通过L-PSA、UL CL等“高速公路”和“立交桥”被引导至网络边缘。然而，在这条路上行驶的车辆——也就是我们主角**“智行一号”**的数据流——首先需要知道它的目的地（EAS - 边缘应用服务器）究竟在哪里。

如果说第四章定义了“路”，那么第五章就是定义了这套系统的“智能导航系统”。这个导航系统由两位紧密配合的角色组成：一位是坐镇网络核心、运筹帷幄的“总调度师”——EASDF；另一位是潜伏在终端内部、忠实执行指令的“一线情报员”——EDC。本章的全部内容，就是围绕着这两位主角的“双人舞”展开的。它们的配合是否默契，直接决定了“智行一号”能否在毫秒之间，从成千上万个可能的边缘节点中，找到那个唯一正确的“最优解”。

1. 5.1 EASDF (边缘应用服务器发现功能)：网络侧的智慧大脑

EASDF (Edge Application Server Discovery Function) 是TS 23.548为5G核心网引入的最重要的新功能实体之一。你可以将它理解为一个被注入了5G网络“灵魂”的超级DNS服务器。它的核心任务不再是简单地将域名翻译成IP地址，而是在这个过程中，利用其在核心网中的独特地位，进行一次充满智慧的、上下文感知的决策。

1.1 5.1.1 功能描述 (Functional Description)

规范通过一系列简洁的列表，精确地定义了EASDF的“职责范围”。让我们逐一拆解，看看这位“总调度师”都具备哪些超能力。

1.1.1 向NRF注册，以便被发现和选择

Registering to NRF for EASDF discovery and selection.

  • 深度解析： 在5G的服务化架构 (SBA) 中，NRF (网络存储库功能) 扮演着“网络功能注册中心”和“黄页”的角色。任何一个网络功能 (NF) 想要被其他NF找到并使用，都必须先去NRF那里“报个到”，声明自己的身份、能力和覆盖范围。

  • EASDF作为一个新增的NF，自然也必须遵守这个规则。它在启动时会向NRF注册，提供的信息可能包括：它所服务的地理区域、支持的网络切片 (S-NSSAI)、容量信息等。

  • 为何重要？ 这个简单的动作是整个服务化体系运作的基础。当SMF需要为某个PDU会话寻找一个合适的EASDF时，它不必硬编码地址，而是直接向NRF查询：“请给我一个能服务北京海淀区、并且支持车联网切片的EASDF实例。” NRF会从它的“黄页”中找到最匹配的EASDF并返回其地址给SMF。

  • 场景代入(“智行一号”)： 当“智行一号”在北京亦庄的自动驾驶示范区启动并建立PDU会话时，为它服务的SMF就会通过NRF，动态地发现并选择了一个专门部署用于服务亦庄区域车联网业务的EASDF。

1.1.2 处理来自SMF的DNS安全信息与指令

Providing DNS security information to SMF.

Handling the DNS messages according to the instruction from the SMF, including:

  • Receiving DNS message handling rules and/or BaselineDNSPattern from the SMF.

  • 深度解析： 这是体现EASDF与5GC深度融合的核心。EASDF并非一个独立自主的DNS，它的行为在很大程度上受到SMF的“遥控”。SMF是会话的管理者，最了解UE的上下文和策略。因此，由SMF向EASDF下发“指令”，告诉它如何处理特定UE或特定业务的DNS请求，是最合理的设计。

  • 这些“指令”就是DNS消息处理规则 (DNS message handling rules)。这些规则非常灵活，可以定义诸如“当收到来自这个UE的、针对*.autodrive.com的查询时，你应该向SMF报告”或者“当收到对legacy.service.com的查询时，你应该直接将它转发给中心的C-DNS”等精细化行为。

  • 场景代入(“智行一号”)： SMF根据“智行一号”的签约信息，向EASDF下发了一条规则：“规则ID: 101；匹配条件：UE IP为X.X.X.X，查询域名为aivision.operator.com；动作：向SMF报告此DNS查询。” 这条规则就像一个“埋伏”在EASDF中的触发器，等待“智行一号”的特定请求。

1.1.3 与UE及后端DNS服务器交换DNS消息

  • Exchanging DNS messages from the UE.
  • Forwarding DNS messages to C-DNS or L-DNS for DNS Query.

  • 深度解析： 这是EASDF作为DNS服务器的基本功。它需要能够接收和解析来自UE的DNS查询报文，并在处理后，将DNS响应报文返回给UE。

  • 在处理过程中，如果EASDF自身无法完成解析（例如，查询的是一个普通的互联网域名，或者需要进行递归查询），它就需要将请求转发给后端的DNS系统，比如部署在核心网的C-DNS或部署在本地的L-DNS。

  • 场景代入(“智行一号”)：

    • “智行一号”查询aivision.operator.com，EASDF收到后，根据SMF下发的规则进行处理。

    • “智行一号”的车载娱乐系统查询music.qq.com，EASDF收到后，发现本地规则不匹配，于是将这个查询转发给运营商的C-DNS，由C-DNS完成对这个公网域名的解析。

1.1.4 智能添加EDNS客户端子网 (ECS) 选项

Adding EDNS Client Subnet (ECS) option into DNS Query for an FQDN.

  • 深度解析： ECS (EDNS Client Subnet) 是一种DNS扩展协议 (RFC 7871)，它允许DNS解析器在向上游DNS服务器查询时，附加上“真实”客户端的IP子网信息。这对于内容分发网络 (CDN) 和全局负载均衡 (GSLB) 至关重要，因为它能帮助权威DNS服务器返回离客户端最近的服务器IP。

  • EASDF的“智能”之处在于，它添加的ECS信息，不一定是UE的IP地址（这可能涉及隐私问题，且UE的IP可能经过了NAT），而是更能代表UE“网络出口拓扑位置”的IP地址。这个地址通常由SMF提供，例如当前为UE服务的L-PSA UPF的N6接口地址。

  • 场景代入(“智行一号”)： SMF知道“智行一号”正通过亦庄边缘节点的L-PSA接入网络，该L-PSA的对外IP是211.138.X.X。当EASDF需要向上游权威DNS查询hdmap.autodrive.com（高精地图服务）时，SMF会指示EASDF在DNS查询中加入ECS选项，内容为211.138.X.0/24。权威DNS看到这个信息，就会返回部署在亦庄数据中心的高精地图服务器的IP，而不是返回一个笼统的北京区域服务器IP。

1.1.5 向SMF报告DNS消息相关信息

Reporting to the SMF the information related to the received DNS messages.

  • 深度解析： 这是实现动态会话分离 (Dynamic Session Breakout) 的关键一步，也是EASDF与SMF联动最精彩的部分。

  • 当EASDF根据SMF下发的规则，匹配到一个需要报告的DNS查询或响应时，它会立刻向SMF发送一个通知。这个通知的内容通常包括UE标识、查询的FQDN、以及解析出的EAS IP地址等。

  • SMF收到这个报告后，就如同收到了一个明确的信号：“注意！这个UE正准备访问一个边缘应用，目的地是这个EAS IP！” SMF随即触发后续动作，例如，为这个EAS IP配置UL CL分流规则，并插入一个L-PSA，从而动态地为这个应用数据流建立一条优化的边缘路径。

  • 场景代入(“智行一号”)： “智行一号”查询aivision.operator.com。EASDF匹配了我们之前提到的规则101，将查询报告给SMF。SMF收到报告后，立即采取行动：

    1. 选择一个靠近“智行一号”的L-PSA UPF。

    2. 向UL CL UPF下发N4规则：“凡是目的IP为刚刚解析出的AI视觉EAS IP的流量，一律转发到新选的L-PSA。”

    3. 一个为AI视觉业务量身定制的低时延路径就此动态生成。

1.1.6 缓冲或丢弃DNS消息

Buffering/Discarding DNS messages from the UE or DNS Server.

  • 深度解析： 这个功能主要用于应对移动性场景，即边缘重定位 (Edge Relocation)。

  • 想象一下，“智行一号”正在从一个基站覆盖范围移动到另一个，网络正在为它切换L-PSA。在这个切换的瞬间，如果EASDF立即将基于旧位置解析出的EAS IP返回给UE，UE可能会向一个即将不可达的路径发送数据。

  • 此时，SMF可以指示EASDF缓冲 (Buffer) 这个DNS响应，暂时不发给UE，直到新的网络路径建立完毕。或者，SMF也可以指示EASDF直接丢弃 (Discard) 这个响应，因为这个响应已经“过时”了。UE在超时后会重新发起DNS查询，而此时新的网络路径已经就绪，UE的第二次查询就能获得基于新位置的正确EAS IP。

  • 场景代入(“智行一号”)： “智行一号”以60公里/小时的速度行驶，即将进入下一个街区。SMF预判到需要进行边缘重定位，便向EASDF下发指令：“在接下来的500毫秒内，所有来自‘智行一号’的DNS响应全部丢弃。” 随后，SMF执行L-PSA的切换。当“智行一号”的应用因DNS查询超时而重试时，它已经在一个新的网络拓扑下，EASDF会为它解析出下一个街区的最优EAS。

1.2 5.1.2 EASDF的发现与选择 (EASDF Discovery and Selection)

The EASDF discovery and selection is defined in clause 6.3 in TS 23.501.

  • 深度解析： 这句话指明了SMF如何找到EASDF的“寻路方法”。这个过程本身并非在TS 23.548中定义，而是遵循了TS 23.501中定义的标准NF发现流程。

  • 如前所述，这个流程的核心就是SMF查询NRF。在PDU会话建立时，SMF会构建一个包含特定参数的查询请求给NRF，例如：{NF Type: EASDF, Target DNN: "autodrive", Serving Area: TAI-list-A}。NRF根据这些参数，从已注册的EASDF实例中，筛选出最合适的一个或一组，返回给SMF。SMF再根据负载均衡等策略，选择最终服务的EASDF。

2. 5.2 边缘DNS客户端 (EDC) 功能：终端侧的忠诚代理

如果说EASDF是运筹帷幄的将军，那么EDC (Edge DNS Client) 就是潜伏在UE内部，确保军令如山的忠诚士兵。没有EDC，EASDF的智慧将无从施展。

2.1 5.2.1 功能描述 (Functional Description)

The Edge DNS Client (EDC) functionality is a 3GPP functionality in the UE that ensures that DNS requests from applications are sent to the DNS Server’s (e.g. EASDF/DNS resolver) IP address received from the SMF in the ePCO.

  • 深度解析： 这是对EDC核心使命最精辟的概括——确保DNS请求被发送到SMF指定的服务器地址。ePCO (extended Protocol Configuration Options) 是5G NAS信令中用于在网络和UE之间透明传输IP层配置参数的一种机制。网络（SMF）正是通过PDU会話建立/修改过程中的ePCO，将选定的EASDF的IP地址“告知”UE。

  • EDC功能的存在，解决了边缘发现机制中最不确定的一环——用户的行为。在智能手机上，用户可以随意修改DNS设置（例如，设置为Google的8.8.8.8或Cloudflare的1.1.1.1），或者使用支持DoH/DoT（DNS over HTTPS/TLS）的应用。这些行为都会绕过运营商指定的DNS，从而导致EASDF机制失效。EDC的使命，就是在操作系统层面或更底层，保证流向边缘应用的DNS查询，必须走“官方通道”。

NOTE 1: A UE without EDC functionality can use the EAS (re-)discovery functionalities provided by EASDF, but the usage of the EASDF cannot be ensured since it may use a different DNS server from the DNS server provided by the operator.

  • 深度解析： 这个附注非常重要。它说明了EDC并非“必须”，但却是实现可靠边缘发现的“保障”。没有EDC的UE，如果它恰好使用了运营商默认的DNS，那么请求还是有可能到达EASDF。但这种“可能”对于需要高可靠性的业务（如自动驾驶）是不可接受的。因此，支持EDC是一项重要的UE能力。

在“Figure 5.2-1: EDC functionality in the UE”中，规范清晰地展示了EDC在UE内部的逻辑位置：它位于应用（EDC consumer）和UE的通信协议栈之间，作为DNS请求的必经之路。

EDC的核心职责可以分解为以下几点：

2.1.1 能力通告与配置接收

A UE that hosts the EDC functionality indicates its capability in the PCO during the PDU Session Establishment…

Configures the DNS Client with the DNS Server’s configuration (IP address and, conditionally, DNS security information of the EASDF/DNS resolver…) received from the SMF in the ePCO…

  • 深度解析： 这是一个双向的交互。

    1. UE → 网络 (能力通告): “智行一号”在建立PDU会话时，会通过PCO告诉网络：“报告，我已装备了EDC功能，随时可以接受指令。”

    2. 网络 → UE (下发配置): SMF收到这个信息后，就会放心地将它为这个会话选择的EASDF的IP地址等配置信息，通过PCO打包，在PDU Session Establishment Accept消息中发回给“智行一号”。“智行一号”的EDC模块接收并应用这个配置。

2.1.2 履行DNS客户端职责

  • Provides the capability to the consumer in the UE to resolve FQDN…
  • Sends DNS Queries towards the DNS Server indicated by the SMF…
  • Forwards EAS IP addresses… to the consumer in the UE.
  • 深度解析： 这三点描述了EDC作为一个标准DNS客户端的行为。当“智行一号”的任何一个应用需要解析域名时，EDC都会接管这个请求，将其打包成DNS查询报文，发送给已经配置好的EASDF地址，然后等待响应，并将响应中的IP地址返回给发起请求的应用。这个过程对上层应用是完全透明的。

2.1.3 关键的触发条件

EDC在什么时候必须被使用？规范给出了明确的条件：

When the UE performs an FQDN resolution request for an application, the UE shall use the EDC functionality to perform the DNS resolution in one of the following cases:

  • the application mapped onto the PDU Session explicitly requests the use of the EDC functionality…
  • the SMF indicated… that the use of the EDC functionality is required for the PDU Session for the specific DNN.

  • 深度解析： 这里定义了两种强制使用EDC的场景：

    1. 应用主动请求： 一个“边缘原生”的应用，可以调用特定的API来请求使用EDC，以确保获得最佳的边缘体验。

    2. 网络强制要求： 这是更常见和更强大的机制。SMF可以在建立PDU会话时，对某个特定的DNN（例如，autodrive.mnc01.mcc262.gprs）或整个PDU会话，强制要求使用EDC。

  • NOTE 4 和 NOTE 5 进一步强调了其强制性：“用户在操作系统层面的DNS偏好设置在EDC启用时不适用”以及“运营商是否可以强制UE使用EDC功能，取决于当地的法规要求”。这为运营商保障其网络服务质量提供了技术抓手。

  • 场景代入(“智行一号”)： “智行一号”用于关键驾驶任务的PDU会话，连接的是一个专用的车联网DNN。运营商和汽车制造商达成协议，SMF对这个DNN的所有会话都下发了“强制使用EDC”的指令。这样，无论车载信息娱乐系统如何设置，都无法干扰到核心驾驶系统对EASDF的访问，从而保障了行车的安全性。

3. 总结：一场完美的双人舞

第五章通过对EASDF和EDC的精细定义，为我们揭示了5G智能边缘发现机制的核心奥秘。这不再是传统DNS的简单查询与响应，而是一场由网络和终端协同出演的、充满智能交互的“双人舞”：

  • SMF 作为“编舞”，在PDU会话建立时，根据UE的能力和业务需求，选定“舞伴”(EASDF)，设定“舞步”(DNS处理规则)，并通过PCO将这些信息传达给UE。

  • EDC 作为UE侧的“舞者”，忠实地接收编舞的指令，确保每一次需要解析边缘应用时，都精准地向指定的“舞伴”EASDF发起“邀约”(DNS查询)。

  • EASDF 作为网络侧的“舞者”，在收到“邀约”后，利用自己的智慧和从SMF获取的实时“舞台信息”(UE网络上下文)，做出最优的决策，并通过响应，引导UE的数据流走向正确的“舞台位置”(EAS)。

这场双人舞，优雅地解决了边缘计算的“发现鸿沟”，为“智行一号”这样的移动终端，在复杂多变的网络环境中，提供了一条清晰、可靠、智能的通往边缘应用之路。

FAQ环节

Q1：如果UE不支持EDC功能，5G边缘计算就完全不能用了吗？

A1：并非完全不能用，但效果和可靠性会大打折扣。如规范NOTE 1所述，没有EDC的UE，网络无法保证其DNS请求一定会发送到EASDF。如果用户使用了公共DNS，那么边缘发现就会失败或次优。网络可能需要依赖一些更复杂的、侵入性更强的技术（如透明DNS代理）来尝试截获DNS流量，但这会增加网络复杂性。因此，EDC是实现原生、高效5G边缘计算的关键UE能力。

Q2：EASDF和L-DNS都是DNS服务器，我应该如何区分它们？

A2：可以从三个维度区分：1) 部署与身份： L-DNS是部署在本地的通用DNS服务器，而EASDF是5G核心网的一个网络功能(NF)，身份不同。2) 智能来源： L-DNS的“智能”主要来源于其部署位置带来的静态拓扑知识。而EASDF的“智能”来源于它能与SMF等核心网元实时交互，获取UE动态的、精细化的会话上下文信息。3) 控制方式： L-DNS的行为通常由其自身配置决定，而EASDF的行为则受到来自SMF的动态指令（DNS消息处理规则）的严格控制。

Q3：我的应用如何知道当前连接的是一个边缘服务器还是中心服务器？

A3：从应用本身的角度，它只知道一个IP地址和端口，通常无法直接区分。然而，整个边缘计算体系可以通过其他方式让应用“感知”到。例如，AF（应用功能）可以订阅网络事件，当UE的边缘路径建立或变更时，网络可以通知AF，AF再通过应用层信令通知客户端。另外，应用也可以通过测量与服务器的往返时延（RTT）来间接判断，连接到边缘服务器的RTT通常会显著低于中心服务器。

Q4：EASDF报告DNS查询信息给SMF，这个过程会增加时延吗？

A4：会的，但这是一种“为了更快而付出的必要代价”。EASDF与SMF之间的交互确实会为首次DNS解析增加几十毫秒的信令时延。但是，这次交互的目的是为了触发SMF去建立一条超低时延的用户面“捷径”（通过Session Breakout）。一旦这条捷径建立起来，后续成千上万个应用数据包都将享受到巨大的时延节省。因此，这是一次性的、用可控的信令面时延，换取持续的、显著的用户面性能优化的典型工程权衡。

Q5：EDC机制是否会对DNS隐私（如DoH/DoT）产生影响？

A5：是的，这是一个非常重要且值得探讨的问题。EDC的设计目标是确保网络对特定业务的DNS解析有控制权，以保障服务质量。这在某种程度上与DoH/DoT等用户自主选择加密DNS的趋势是相悖的。规范通过“强制使用”的机制，实际上是赋予了网络高于用户或应用的DNS选择权。这在公共互联网服务和需要SLA保障的专网服务（如车联网、工业控制）之间形成了张力。未来的发展可能会寻求一种平衡，例如，UE可以对不同应用或PDU会話采用不同的DNS策略，在保障关键业务的同时，也尊重用户对普通上网的隐私选择。

关系图谱