51学通信

深度解析 3GPP TS 23.548：6.2.3.3 & 6.2.3.4 边缘重定位与部署信息管理 (Part 3 - 移动的智慧与数据的罗盘)

23分钟阅读

好的，遵从指令。在上一篇中，我们见证了5G网络如何通过一次DNS查询，为静态的“智行一号”动态构建出一条通往边缘的捷径。但现实世界是运动的，挑战也随之而来。当“智行一号”在城市中穿梭时，那条精心构建的捷径会如何演变？网络又从何处获取智慧，来指导这所有决策？

现在，我们将深入第六章的后续部分，探索5G边缘计算中关于“移动”和“知识”的两大核心议题。

深度解析 3GPP TS 23.548：6.2.3.3 & 6.2.3.4 边缘重定位与部署信息管理 (Part 3 - 移动的智慧与数据的罗盘)

本文技术原理深度参考了3GPP TS 23.548 V18.9.0 (2025-03) Release 18规范中，关于“6.2.3.3 EAS Re-discovery Procedure at Edge Relocation”和“6.2.3.4 EAS Deployment Information Management”的核心章节。本文旨在为读者揭示在最主流的会话分离模型下，当用户移动时，5G系统如何智能地触发应用进行EAS重发现；并进一步探本溯源，剖析网络进行所有这些智能决策所依赖的“数据罗盘”——EAS部署信息是如何被管理和分发的。

在上一章的“大戏”中，我们看到“智行一号”通过一次DNS查询，成功触发SMF为其动态建立了一条通往A区边缘服务器（EAS）的本地分流路径。此刻，它正享受着超低时延的AI视觉分析服务，一切看起来都很完美。

但是，新的挑战接踵而至。“智行一号”并非静止不动，它正沿着城市主干道，从A区驶向B区。这意味着，之前为它服务的A区L-PSA UPF和A区EAS，很快将不再是最佳选择。如果不做任何处理，数据流将不得不“绕远路”，时延会急剧增加，边缘计算的优势将荡然无存。

5G网络将如何应对这一挑战？它如何优雅地指挥“智行一号”的应用层，悄无声息地完成从A区EAS到B区EAS的切换？更进一步，网络做出这一系列决策的依据是什么？它脑中的那幅“边缘地图”又是从何而来？

本篇文章将分为两大部分，为您解答上述两个环环相扣的问题：

  1. 移动的智慧： 解析在会话分离模型下，由移动性或应用请求触发的EAS重发现流程。

  2. 数据的罗盘： 剖析作为所有决策基础的EAS部署信息，及其在5GC中的创建、更新与分发机制。

1. 移动的智慧：6.2.3.3 EAS重发现流程 (EAS Re-discovery Procedure at Edge Relocation)

这个章节是处理会话分离模型下移动性的核心。它定义了一套由网络侧发起、UE侧响应的协同机制，以确保业务在移动过程中的连续性和最优性。

1.1 重发现的“双引擎”：两大触发源

1a. Due to the UE mobility the SMF triggers L-PSA insertion, change or removal for the PDU Session. The insertion, change or removal of L-PSA triggers EAS rediscovery.

1b. The AF triggers EAS relocation e.g. due to EAS load balance or maintenance, etc. and informs the SMF…

  • 深度解析： 规范明确了触发EAS重发现的两种主要动力来源：

    1. 网络侧触发（UE移动）： 这是最常见的场景。SMF作为会话和移动性的管理者，它时刻监控着“智行一号”的位置。当它检测到“智行一号”已进入B区，它会判断出当前服务于A区的L-PSA已不是最优，需要为它更换一个新的、位于B区的L-PSA。这个更换L-PSA的网络层操作，就成为了触发应用层EAS重发现的内生事件。

    2. 应用侧触发（AF请求）： 边缘应用平台（AF）自身也可能发起重定位。例如，A区的AI视觉分析EAS由于计算负载过高，AF的负载均衡系统决定将“智行一号”的业务迁移到负载较轻的B区EAS。此时，AF会通过NEF向SMF发送一个“影响流量路由”的请求，主动要求网络配合进行重定位。

无论是哪种触发源，最终都需要一个机制来通知终端上的应用程序：“是时候换个服务器了！”

1.2 神奇的信使：EAS重发现指示 (EAS rediscovery indication)

  1. …the SMF performs the network requested PDU Session Modification procedure… If the UE has indicated that it supports to refresh EAS information stored locally…, the SMF may send the impact field with the EAS rediscovery indication.

  • 深度解析： 无论触发源是什么，SMF最终都会通过一个标准的5G流程——PDU会话修改（PDU Session Modification）——来向UE下达指令。

  • 这个指令的核心，就是一个名为 EAS rediscovery indication 的信令参数。它就像SMF寄给“智行一号”的一封“鸡毛信”，内容简单明了：“你需要重新进行EAS发现了！”

  • impact field (影响域): 这封“鸡毛信”还可以附带一个“便签”，即影响域。这个便签让指令变得更加精准。SMF可以精确地告诉UE：

    • “你只需要为你正在使用的aivision.operator.com这个服务重新发现服务器。”

    • 或者，“所有之前解析到IP_range_A的边缘服务，都需要重新发现。”

  • 如果没有这个“便签”，UE可能需要清空所有PDU会话相关的DNS缓存，造成不必要的开销。impact field实现了“靶向刷新”。

The SMF sends PDU Session Modification Command (EAS rediscovery indication, [impact field]) to UE. The EAS rediscovery indication indicates to refresh the cached EAS information… For the following connection…, the UE has been instructed not to use the old EAS information stored locally. Instead it should trigger EAS discovery procedure to get new EAS information…

  • 深度解析：

    • UE的响应： “智行一号”的通信模组收到这个PDU会话修改命令后，其内部的EDC或操作系统会解析出EAS rediscovery indication和impact field。

    • 核心动作： UE会根据impact field的内容，清空本地对应的DNS缓存。例如，清除掉 aivision.operator.com → IP_of_EAS_A 这条缓存记录。

    • 触发新发现： 当AI视觉应用下一次尝试连接时，它会发现本地没有可用的IP地址，于是自动触发一次全新的DNS查询。

  • 流程闭环： 这次全新的DNS查询，会重新走一遍我们在上一篇文章中剖析的、由EASDF主导的动态发现流程。但这一次，由于SMF已经（或者即将）将网络路径（L-PSA）切换到了B区，所以EASDF在进行智能解析时，获取到的UE拓扑位置信息将是B区的。因此，这次新查询的最终结果，自然就是B区EAS的IP地址。

  • 场景总结： “智行一号”从A区驶入B区。SMF检测到移动 → SMF决定更换L-PSA到B区 → SMF向UE发送“重发现指示（影响域为AI视觉应用）” → UE清空AI视觉应用的DNS缓存 → 应用发起新的DNS查询 → 新查询通过B区路径到达EASDF → EASDF解析出B区的EAS IP → “智行一号”无缝切换到B区EAS。整个过程在应用层几乎无感，实现了业务的平滑迁移。

2. 数据的罗盘：6.2.3.4 EAS部署信息管理 (EAS Deployment Information Management)

我们已经看到，SMF和EASDF在整个发现和重发现过程中，扮演着决策者的角色。但任何决策都需要依据。SMF如何知道aivision.operator.com是一个边缘应用？EASDF又如何知道在B区恰好就有一个可用的AI视觉服务器？

答案就藏在 EAS部署信息（EAS Deployment Information） 之中。这部分内容定义了边缘应用生态的“数字地图”，是整个5G边缘计算智能体系的“知识库”和“罗盘”。

2.1 地图的核心要素：Table 6.2.3.4-1

规范通过一个表格，详细定义了这份“地图”应该包含哪些关键信息。

| 参数 (Parameters) | 描述 (Description) 与 “智行一号”场景解读 |

| :--- | :--- |

| AF ID | 应用功能（AF）的寻址信息。解读： 这份信息的提供者是谁？是“智行一号”AI视觉平台的开发者。 |

| DNN / S-NSSAI | 该部署信息适用的数据网络名称或网络切片。解读： 这份地图是用于哪个网络的？是用于autodrive这个车联网专用DNN/切片的。 |

| Application ID | 标识该部署信息对应的应用。解读： 这份地图具体是为哪个App准备的？是为AI_Vision_App_v2.1。 |

| FQDN(s) | 应用支持的完全限定域名。解读： 用户通过哪个域名来访问这个服务？aivision.operator.com。 |

| DNAI(s) | 数据网络接入标识符。解读： 【最关键的连接点】 这个服务部署在哪些“本地数据网络”？部署在了IDC-A（A区边缘机房）、IDC-B（B区边缘机房）。DNAI将应用的逻辑存在与网络的物理拓扑关联了起来。 |

| DNS Server Information | 每个DNAI的DNS服务器列表。解读： 如果IDC-A有自己的L-DNS，这里会提供其IP地址。 |

| EAS IP address range Information | 每个DNAI中EAS的IP地址或地址范围。解读： 在IDC-A机房里，AI视觉服务器的具体IP地址段是21.34.56.0/24。这是SMF配置UL CL规则的直接依据。 |

| N6 traffic routing information | 如何在本地DN中转发边缘流量的信息。解读： 当流量到达IDC-A的L-PSA后，该如何通过机房内部网络路由到具体的服务器机柜。这是更深层次的路由信息。 |

这份信息表，就是SMF和EASDF进行决策的“圣经”。当EASDF收到对aivision.operator.com的查询时，它会查阅这张表，得知这个服务在多个DNAI都有部署。再结合从SMF处获取的UE当前位置信息（例如，UE正由能够接入IDC-B的UPF服务），EASDF就能做出“应该返回IDC-B的EAS IP”这一精准决策。

2.2 地图的绘制与分发：两大管理流程

这么重要的地图，是如何被绘制出来，并分发到需要它的“决策者”（如SMF）手中的呢？规范定义了两个核心管理流程。

流程一：从应用到网络 - AF提供部署信息 (6.2.3.4.2)

这个流程描述了“地图绘制者”（应用提供商AF）如何将地图提交给“地图管理者”（5G核心网）。

The AF provides non-PDU Session specific EAS Deployment information to 5GC via the procedure defined in this clause.

  • 深度解析：

    1. 入口 (Gateway): AF通过NEF (网络能力开放功能) 这个标准的北向接口与5GC进行交互。NEF是应用生态与运营商网络之间的安全、可控的桥梁。

    2. 动作 (Action): AF调用Nnef_EASDeployment_Create/Update/Delete服务，将包含Table 6.2.3.4-1中所有信息的“部署地图”数据，提交给NEF。

    3. 存储 (Storage): NEF在对AF的请求进行鉴权和策略检查后，会将这些信息写入到UDR (统一数据存储库) 中。UDR是5GC的中央数据库，用于持久化存储各类重要数据。

  • 场景代入： “智行一号”的AI平台进行了一次升级，在C区新建了一个边缘计算节点。平台的运维人员（作为AF）会立刻调用NEF的API，向5GC提交一条新的部署信息，将IDC-C及其对应的EAS IP地址等信息，添加到aivision.operator.com的部署列表中。

流程二：从网络核心到决策者 - SMF获取部署信息 (6.2.3.4.3)

这个流程描述了“决策者”（SMF）如何获得并保持自己手中的地图是最新版本。

The SMF may receive the EAS Deployment Information from NEF via Subscribe /Notify procedure…

  • 深度解析： SMF并不会在每次需要时都去查询UDR，这种效率太低。它采用了一种更高效的**“订阅-通知”**模型。

    1. 订阅 (Subscribe): SMF在启动或配置更新时，会向NEF发起订阅。订阅请求的内容是：“我对所有关于DNN为autodrive的EAS部署信息都感兴趣。当这些信息有任何增、删、改时，请立刻通知我。”

    2. 通知 (Notify): 当C区的AI视觉节点成功部署，AF通过NEF更新了UDR中的信息后，UDR会触发一个通知给NEF（因为NEF也可能订阅了UDR）。NEF收到更新后，会立即查找所有订阅了相关信息的SMF列表，并向它们逐一发送Notify消息，将最新的“地图”版本推送给它们。

  • 结果： 通过这种机制，所有管理车联网业务的SMF，都能近乎实时地在自己的内存中，拥有一份与UDR同步的、最新的“全国边缘节点部署地图”，从而确保了它们在为“智行一号”进行决策时的准确性和时效性。

4. 总结：智慧移动的闭环

通过对6.2.3.3和6.2.3.4章节的联合剖析，我们构建了一个关于5G边缘计算如何应对移动性的完整认知闭环：

  • 决策基础 (Data Plane): EAS部署信息定义了静态的“世界地图”，它由应用方（AF）通过NEF注入到网络（UDR），并通过订阅-通知机制分发给决策者（SMF）。

  • 移动感知 (Network Plane): SMF作为移动性管理的“中枢”，能够实时感知到UE的拓扑位置变化，并决定何时需要进行网络路径（L-PSA）的切换。

  • 指令下达 (Control Plane): 当网络路径变化时，SMF通过PDU会话修改流程，向UE发送一个精准的**EAS rediscovery indication**信令。

  • 终端执行 (UE Plane): UE（的EDC/OS）在收到指令后，忠实地执行DNS缓存清理的动作。

  • 应用触发 (Application Plane): 应用在缓存失效后，重新发起DNS查询，这又回到了我们熟悉的、由EASDF主导的智能发现流程，最终解析到新的、最优的EAS。

这五个环节，从静态数据到动态信令，再到最终的应用行为，形成了一个优雅而健壮的闭环，完美地诠释了5G网络如何将自身的移动性管理能力，转化为对上层应用的智能引导和无缝赋能。

FAQ环节

Q1：EAS重发现（Re-discovery）和边缘重定位（Edge Relocation）有什么区别？

A1：这两个术语紧密相关但侧重点不同。EAS重发现特指UE侧发起的、用于寻找新的EAS IP地址的DNS发现流程。它是一个“应用层”的动作。而边缘重定位是一个更宏观的、端到端的概念，它包含了网络层和应用层的全部动作。一次完整的边缘重定位，通常包括：SMF决定更换L-PSA（网络层），SMF触发UE进行EAS重发现（信令），UE执行重发现（应用层），以及最终业务流量切换到新的EAS（用户面）。可以说，EAS重发现是边缘重定位过程中的一个关键环节。

Q2：AF（应用功能）是如何知道SMF的地址，以便向它发送重定位请求的？

A2：AF通常并不知道也不需要知道具体为某个UE服务的SMF的地址。AF的交互对象始终是NEF（或PCF）。AF向NEF提交一个“影响流量路由”的请求，请求中会包含UE的标识（如GPSI）、应用的标识等。NEF会将这个请求路由给PCF，PCF再根据这些信息，生成策略下发给正确的SMF。这种通过NEF/PCF进行解耦的方式，保护了核心网内部的拓扑信息，并提供了一个统一、安全的API入口。

Q3：EAS部署信息的更新是实时的吗？如果我刚刚下线一个服务器，网络能立刻知道吗？

A3：这取决于整个信息同步链路的速度。从AF调用NEF API，到NEF更新UDR，再到NEF通知SMF，整个过程都是基于服务化的接口调用，在理想的网络环境下，可以做到秒级甚至亚秒级的同步。这确保了SMF手中的“地图”具有很高的时效性。当一个EAS被下线时，运维系统应该立即通过AF接口从UDR中删除该条目，SMF收到通知后，就不会再将用户引导至该服务器，甚至可以主动为正在使用该服务器的用户触发一次EAS重发现。

Q4：如果SMF发送了EAS rediscovery indication，但UE由于某种原因没有执行缓存清理，会发生什么？

A4：这会导致一个“网络与应用状态不一致”的问题。SMF可能已经将网络路径切换到了B区，但UE的应用层仍然持有A区EAS的IP地址，并继续向其发送数据。这些数据包会通过新的B区L-PSA，再经由骨干网，绕行到A区的EAS。这会导致路由迂回和时延增加。虽然业务不一定会中断，但边缘计算的性能优势将完全丧失。这再次凸显了UE遵循网络信令建议的重要性。

Q5：这些复杂的流程是不是只适用于像“智行一号”这样的高端物联网设备？普通手机能支持吗？

A5：这些流程是为所有支持5G边缘计算的UE设计的，包括普通智能手机。关键在于手机的操作系统（OS）和基带模组是否实现了相关的3GPP规范，特别是EDC功能以及对PDU会話修改命令中EAS rediscovery indication的解析和响应能力。随着5G Advanced的发展和边缘应用（如云游戏、XR）的普及，新出厂的高端智能手机预计将逐步原生支持这些功能，从而让普通消费者也能享受到无缝的边缘计算体验。

关系图谱