51学通信

深度解析 3GPP TS 23.548：6.2 EAS 发现与重发现 (Part 1 - 分布式锚点模型)

27分钟阅读

好的，遵从指令。我们已经搭建好了5G边缘计算的架构舞台，并认识了台上的两位核心主角EASDF和EDC。现在，大幕将启，我们将进入规范中最为核心、最为详尽的第六章，观看这场边缘发现与重定位的“实战大戏”是如何上演的。

由于第六章内容极其丰富和庞大，我们将遵循拆分原则，本文将作为“第六章系列”的第一篇，聚焦于最基础也是最根本的流程：在分布式锚点模型下的EAS发现与重发现。

深度解析 3GPP TS 23.548：6.2 EAS 发现与重发现 (Part 1 - 分布式锚点模型)

本文技术原理深度参考了3GPP TS 23.548 V18.9.0 (2025-03) Release 18规范中，关于“Chapter 6 Procedures for Supporting Edge Computing”的 6.1, 6.2.1 和 6.2.2 章节，旨在为读者详细拆解5G系统中最基础的边缘应用服务器（EAS）发现流程，特别是针对分布式锚点（Distributed Anchor）这一特定连接模型下的实现机制与移动性下的重发现过程。

在前面的章节中，我们已经描绘了5G为边缘计算所设计的宏伟蓝图（Chapter 4），并深入了解了实现这一蓝图的两位核心“智能体”——EASDF与EDC（Chapter 5）。我们知道了“路”该如何修，“导航系统”具备哪些功能。现在，我们将进入TS 23.548的“实践篇”——第六章，亲眼见证车辆（数据流）是如何在这条崭新的智慧道路上，通过智能导航，精确地找到并驶向其动态变化的目的地。

本章是规范的“动作核心”，详细定义了支持边缘计算的各类流程。为了循序渐进，我们将首先聚焦于最 foundational（基础）的场景。我们的老朋友，自动驾驶物流车**“智行一号”，今天将在一个大型的智慧物流港区开始它的工作。为了保障其核心安全驾驶功能的绝对可靠和最低时延，港区网络为它规划了一条“VIP专用通道”——一个基于分布式锚点连接模型**的专用PDU会话。

我们将跟随“智行一号”从启动、连接网络，到在港区内移动的全过程，来一步步拆解5G网络是如何帮助它完成首次的EAS发现，以及在移动过程中如何无缝地进行EAS重发现的。

1. 6.1 General (概述)：所有流程的总目标

第六章的开篇，首先为本章所有复杂的流程定下了一个清晰的基调和总目标。

Edge Computing enables operator and 3rd party services to be hosted in EAS close to the UE’s point of attachment. The traffic to EAS can be routed based on the UE position and EAS availability “near to” that position.

  • 深度解析： 这句话再次强调了边缘计算的本质——“就近服务”。而实现这一点的核心手段，就是让流量的路由能够基于UE的位置和EAS的可用性进行动态决策。第六章的所有流程，无论是发现、重发现、还是重定位，都是为了实现这个“动态路由”的目标而服务的。

规范接着列出了本章将要描述的几大核心流程：

The subsequent clauses describe the procedures for supporting Edge Computing in 5G System considering different connectivity models, including:

  • EAS discovery and re-discovery.
  • Edge relocation.
  • Network exposure to Edge Application Server.
  • Support of 3GPP application layer architecture defined in TS 23.558.
  • Support of AF guidance to PCF determination of proper URSP rules.

  • 深度解析： 这个列表构成了我们后续系列文章的“剧本大纲”。

    • EAS发现与重发现是所有故事的起点，是本次我们关注的焦点。

    • 边缘重定位则关注在更复杂的移动场景下，网络和应用如何协同进行切换。

    • 后续的网络开放、应用层架构支持以及AF指导等，则是在基础连接之上，实现更高级“网业协同”的“进阶玩法”。

2. 6.2 EAS Discovery and Re-discovery (EAS发现与重发现)的通用原则

在进入具体流程之前，6.2.1节首先定义了所有“发现”类流程都必须遵循的一些通用原则和基础机制。

2.1 6.2.1 General (通用原则)

EAS discovery is the procedure by which a UE discovers the IP address(es) of a suitable Edge Application Server(s) using Domain Name System (DNS). EAS Re-discovery is the EAS Discovery procedure that takes place when the previously discovered Edge Application Server cannot be used or may have become non-optimal (e.g. at edge relocation).

  • 深度解析： 这里给出了两个核心概念的精确定义：

    • 发现 (Discovery): 从无到有的过程。即“智行一号”启动后，第一次去寻找为它服务的港区交通调度EAS的IP地址。

    • 重发现 (Re-discovery): 从旧到新的过程。当“智行一号”从港区的A作业区移动到B作业区，之前连接的A区EAS不再是最佳选择时，它需要重新发起一次发现流程，找到B区的EAS。这个过程就叫重发现。本质上，重发现就是一次被特定事件（如移动）触发的新的发现。

接下来，规范揭示了实现“智能发现”的底层技术魔术：

In order to provide a translation of the FQDN of an EAS into the address of an EAS as topologically close as possible to the UE, the Domain Name System may use following information:

  • The source IP address of the incoming DNS Query; and/or,
  • an EDNS Client Subnet (ECS) option (as defined in RFC 7871).

  • 深度解析： 这是整个智能发现机制的“信息输入”。DNS系统（无论是L-DNS还是EASDF）如何判断UE的“拓扑位置”？答案就在这里：

    1. 查询源IP地址： DNS查询请求到达DNS服务器时，会携带源IP地址。在5G边缘计算架构中，这个源IP通常是L-PSA UPF的N6接口地址。由于L-PSA本身就是靠近UE的，所以这个IP地址就能很好地代表UE的网络接入位置。

    2. EDNS客户端子网 (ECS)： 这是一种更明确、更强大的机制。网络（如EASDF）可以在DNS查询中，显式地插入一个ECS字段，内容是代表UE网络位置的IP子网信息（例如L-PSA的N6接口子网）。权威DNS服务器看到这个ECS信息，就能进行精确的智能解析。

  • 场景代入(“智行一号”)： “智行一号”在港区的A作业区，其PDU会话锚定在A区的L-PSA UPF上。当它发起DNS查询时，这个查询经过A区的L-PSA。DNS系统看到查询来自A区的L-PSA（通过源IP或ECS），就如同听到了一个明确的地理坐标信号：“请求来自A作业区！” 于是，它便会返回部署在A区边缘机房的EAS的IP地址。

规范也强调了这一切的可靠性保障：

If the UE applications want to discover/access EAS by using the mechanisms defined in this TS, the UE shall support receiving DNS settings in PCO during PDU Session Establishment… and the DNS Queries generated by the UE for these applications shall be sent to the DNS server/resolver (e.g. EASDF) indicated by the SMF. To ensure this, the application in the UE either requests the EDC functionality…

  • 深度解析： 这段话重申了我们在第五章学到的知识，形成了一个完美的逻辑闭环。要想让上述基于源IP/ECS的智能发现机制可靠地工作，就必须保证DNS请求能被发送到“懂”这些规则的DNS服务器（即EASDF或L-DNS）。而保证这一点的机制，就是PCO下发DNS配置 + UE侧EDC功能的遵从执行。这形成了一个从网络策略制定到终端执行的完整链条。

3. 6.2.2 分布式锚点模型下的发现流程 (EAS (Re-)discovery over Distributed Anchor Connectivity Model)

现在，我们进入本章的第一个实战流程。分布式锚点模型是架构最简洁的一种：整个PDU会话的用户面锚点都被设置在了网络边缘的一个L-PSA UPF上。

3.1 6.2.2.2 EAS Discovery Procedure (EAS发现流程)

这个流程描述了“智行一号”在它的“VIP专用通道”上，如何进行首次的EAS发现。

For the Distributed Anchor connectivity model, in PDU Session Establishment procedure, the SMF selects a DNS Server for the PDU Session. The DNS Server is configured to UE via PCO… The SMF determines the DNS server address for the PDU Session based on local configuration and EAS Deployment Information provided by AF when applicable.

  • 深度解析： 流程的第一步，发生在PDU会话建立之时。

    • SMF选择DNS服务器： 当SMF为“智行一号”建立这个专用的、基于分布式锚点的PDU会话时，它就已经根据UE的位置和DNN等信息，决定了这个会话应该使用哪个DNS服务器。因为是分布式锚点，所有流量都本地化，所以SMF通常会选择一个与该L-PSA UPF配套的L-DNS（本地DNS）。

    • 通过PCO下发配置： SMF将选定的L-DNS的IP地址，打包进PCO（协议配置选项），通过PDU Session Establishment Accept消息发送给“智行一号”。

    • UE侧配置： “智行一号”的EDC模块收到PCO后，就将这个L-DNS地址配置为本PDU会话的专用DNS服务器。

  • 场景代入(“智行一号”)： “智行一号”在A作业区启动，请求建立一个用于核心安全驾驶的PDU会话。SMF识别出这个请求，为其选择A作业区的L-PSA UPF作为锚点，并同时选择了与该UPF配套的A区L-DNS。SMF将A区L-DNS的IP地址通过PCO下发。“智行一号”配置完毕，现在它知道，所有在这个“VIP通道”里的DNS查询，都应该去问A区的L-DNS。

DNS服务器已指定，接下来的解析过程如何进行？

For Distributed Anchor Point connectivity model, in order to provide addressing information to the DNS system that is related to the UE topological location, when a DNS Query is sent via the Local PSA UPF,

  • either the DNS Query is resolved by a DNS resolver, which then adds a DNS EDNS Client Subnet option…
  • or the DNS Query is resolved by a DNS server that is close to the PSA UPF…

  • 深度解析： 这里描述了两种具体的解析机制，与我们在6.2.1中看到的通用原则完全对应。

    1. 机制A：L-DNS作为解析器（Resolver）并添加ECS。 “智行一号”向A区的L-DNS发送查询。L-DNS不直接回答，而是扮演一个“聪明的中间人”。它根据查询的源IP（即A区L-PSA的IP），生成一个ECS字段，然后带着这个ECS信息去查询更上层的权威DNS。权威DNS根据ECS信息返回最优的EAS IP。

    2. 机制B：L-DNS作为权威服务器（Authoritative Server）。 A区的L-DNS本身就直接管理着A区所有边缘应用的域名记录。当它收到“智行一号”的查询时，直接在自己的“账本”里查找，然后返回A区EAS的IP。这种方式更直接，延迟更低，非常适合纯本地化的边缘服务。

  • 场景代入(“智行一号”)： “智行一号”的应用发起对 port-crane-control.smartpark.com（港区起重机控制服务）的DNS查询。

    • 在机制B下： A区L-DNS收到查询后，立即从本地记录中找到并返回了A区起重机控制EAS的IP地址。一次极速的、纯本地的发现过程完成。

3.2 6.2.2.3 边缘重定位时的重发现流程 (EAS Re-discovery Procedure at Edge Relocation)

这是分布式锚点模型下处理移动性的核心。这个流程巧妙地利用了5G会话与服务连续性（SSC）模式2或3的特性。

背景知识：SSC Mode 2/3

  • SSC Mode 2: Before new session is established, the old one is released. 会话“先断后通”，期间可能会有短暂中断，但UE的IP地址会保持不变。

  • SSC Mode 3: New session is established before the old one is released. 会话“先通后断”，可以实现无缝切换，期间UE会临时拥有两个IP地址/前缀。

  • 共同点： 在这两种模式下，当UE发生移动，需要更换PDU会话锚点（PSA UPF）时，网络可以发起一个“锚点重定位”流程，将PSA从旧的UPF切换到新的UPF，而对上层应用来说，业务是连续的。

现在，让我们看看当“智行一号”移动时会发生什么。

In order to change the PDU Session Anchor serving a PDU Session of SSC mode 2/3 for a UE, SMF triggers session continuity… procedures… During these procedures… it is recommended that the UE applies the following behaviour:

The UE DNS cache should be bound to the IP connection. When the UE detects the PDU Session release or new IP prefix is allocated within the PDU Session, the UE removes the old DNS cache related to old/removed IP address/prefix…

  • 深度解析： 这是整个流程中最精妙的“机关”所在。

    • 移动触发锚点变更： “智行一号”从A作业区移动到了B作业区。SMF检测到这一移动，决定将其PDU会话的锚点从A区的L-PSA UPF，切换到B区的L-PSA UPF。这个切换过程遵循SSC Mode 3，是无缝的。

    • 网络路径变化： 切换后，“智行一号”会获得一个新的IP前缀，并且其所有的数据流（包括DNS查询）都将通过新的B区L-PSA UPF进行路由。

    • UE的推荐行为——清空DNS缓存： 规范强烈推荐，当UE检测到其IP连接发生变化（如获得了新的IP前缀）时，应该主动清空与旧IP地址/前缀关联的DNS缓存。

  • 为什么清空缓存如此关键？ 因为如果不清空，“智行一号”的操作系统里可能还缓存着 port-crane-control.smartpark.com → IP_of_EAS_A 这个旧的映射。即使网络路径已经切换到了B区，应用层可能仍然会尝试连接远在A区的EAS，导致性能下降甚至连接失败。

清空缓存后，重发现的流程就变得水到渠成。

With this behaviour, when the establishment of a new PDU Session triggers EAS rediscovery for an FQDN, the UE can reselect a new EAS for that FQDN.

…In step 5, the UE can reselect a new EAS for the FQDN with an EAS Discovery procedure if the recommended UE behaviour has been followed.

  • 深度解析：

    1. 当“智行一号”的应用在锚点切换后，再次尝试访问 port-crane-control.smartpark.com 时，它会发现本地没有DNS缓存记录。

    2. 于是，它会发起一次新的DNS查询。

    3. 这次查询，因为网络路径已经切换，将通过新的B区L-PSA UPF，被发送到B区的L-DNS。

    4. B区的L-DNS执行与6.2.2.2节完全相同的发现流程，但因为它是在B区的环境中，所以它自然地解析出了B区起重机控制EAS的IP地址。

    5. 应用获得了新的、最优的EAS IP，并与之建立连接。服务无缝地从A区EAS切换到了B区EAS。

  • 总结： 在分布式锚点模型下，EAS的重发现被巧妙地设计成了一个由5G网络层移动性事件（PSA重锚定）触发，由UE侧推荐行为（清空DNS缓存）驱动的，一个几乎是“自动发生”的过程。它不需要复杂的应用层信令交互，而是优雅地利用了IP网络的底层机制，实现了高效的应用层服务连续性。

4. 总结：简约而不简单

通过对6.2.2章节的深度剖析，我们完成了对5G边缘计算最基础发现流程的解读。分布式锚点模型下的发现与重发现机制，向我们展示了3GPP设计的智慧：

  • 流程的起点是PDU会话建立，网络在此时就通过PCO为UE“指定”了正确的本地化DNS服务器，为后续的精准发现奠定了基础。

  • 发现的核心是利用网络拓扑信息，通过DNS查询的源IP或更明确的ECS选项，让DNS系统能够感知到UE的接入位置，从而做出最优解析。

  • 移动性的解决则依赖于网络与终端的默契配合，SMF负责网络路径的无缝切换（SSC Mode 2/3），而UE则通过响应IP连接变化来清空DNS缓存，从而自然地触发一次导向新位置的重发现。

我们跟随“智行一号”完成了它在专用通道上的首次任务。这个过程虽然看起来相对简单，但它揭示的“PCO下发配置 → DNS查询携带位置信息 → DNS系统智能解析 → 移动性触发IP变化 → UE清缓存并重查询”这一系列核心逻辑，将会在后续更复杂的场景中反复出现。

在下一篇文章中，我们将进入到更具挑战性也更为普遍的**会话分离（Session Breakout）**模型。在那个模型中，EAS的发现过程本身，将会动态地“创造”出通往边缘的路径。敬请期待！

FAQ环节

Q1：在分布式锚点模型下，如果我的UE不支持SSC Mode 2/3，会发生什么？

A1：如果UE只支持SSC Mode 1（即每次移动都保持PSA锚点不变），那么它在移动时将无法享受到EAS重发现带来的好处。它的PDU会话将始终锚定在初始的L-PSA UPF上。当“智行一号”从A区移动到遥远的Z区，它的数据流仍然需要绕回A区的UPF，再路由到Z区的EAS，这将导致时延急剧增加，失去了边缘计算的意义。因此，SSC Mode 2/3是实现移动场景下分布式锚点模型价值的关键。

Q2：UE清空DNS缓存这个行为是强制性的吗？如果UE没有这么做会怎样？

A2：规范的用词是“it is recommended that the UE applies the following behaviour”（推荐UE应用以下行为），这表明它并非一个强制性的协议要求，而是一种最佳实践建议。如果UE没有遵循这个建议，那么在PSA锚点切换后，它的应用可能会继续使用缓存中的旧EAS IP地址进行通信。数据包仍然会通过新的B区L-PSA路由，但目的地却是远在A区的EAS。这会导致所谓的“次优路由”，虽然业务可能不会完全中断，但时延会显著增加，违背了边缘计算的初衷。

Q3：分布式锚点模型听起来很简单，为什么不所有边缘业务都用它？

A3：分布式锚点模型的主要缺点是缺乏灵活性和IP地址稳定性差。一旦建立，该PDU会話上的所有流量（无论边缘业务还是普通上网）都会从本地出口出去，无法实现精细化分流。更重要的是，由于PSA锚点会随着UE移动而频繁改变（在SSC Mode 2/3下），这可能导致UE的IP地址/前缀也频繁变化，对于需要保持长连接或稳定IP地址的应用来说，可能会带来困扰。相比之下，会话分离模型可以保持一个稳定的中心锚点和IP地址，只对特定流量进行分流，因此更为通用。

Q4：谁来决定一个PDU会话是采用分布式锚点模型还是其他模型？

A4：这通常由SMF根据多种信息综合决定。这些信息包括：1) 用户签约数据： 用户的签约信息中可能就规定了某个DNN只能用于建立分布式锚点的边缘会话。2) UE请求： UE在发起PDU会话建立请求时，可能会携带特定的DNN或S-NSSAI，暗示了其业务类型。3) 网络策略： 运营商可以配置本地策略，例如，规定某个特定区域（如工业园区）内所有物联网终端的默认会话都采用分布式锚点。

Q5：在这个流程中，似乎主要是L-DNS在起作用，EASDF体现在哪里？

A5：您观察得很敏锐。在分布式锚点这个相对简单的模型下，由于锚点和流量路径在会话建立时就已经完全本地化，使用一个了解本地情况的L-DNS通常就足够了。然而，EASDF的能力是L-DNS的超集。SMF完全可以选择一个EASDF作为这个PDU会话的DNS服务器。在这种情况下，EASDF依然可以通过与SMF的交互，获取关于这个分布式锚点会话的精确信息（例如L-PSA的特性），从而做出同样甚至更精准的解析。EASDF真正的威力将在下一章的“会话分离”模型中得到淋漓尽致的展现，因为它需要处理更复杂的、尚未建立本地路径的发现请求。

关系图谱