51学通信

深度解析 3GPP TS 23.548：6.2 EAS 发现与重发现 (Part 2 - 会话分离模型与动态锚点)

24分钟阅读

好的，遵从指令。我们继续这场深入3GPP TS 23.548规范的旅程。在前一篇文章中，我们剖析了在最简洁的“分布式锚点”模型下，EAS的发现与重发现流程。现在，我们将进入一个更为复杂、更为灵活，也更为普遍的场景——会话分离 (Session Breakout) 模型。

深度解析 3GPP TS 23.548：6.2 EAS 发现与重发现 (Part 2 - 会话分离模型与动态锚点)

本文技术原理深度参考了3GPP TS 23.548 V18.9.0 (2025-03) Release 18规范中，关于“Chapter 6 Procedures for Supporting Edge Computing”的 6.2.2.4 和 6.2.3 章节，旨在为读者深度剖析5G系统中最核心、最灵活的会话分离（Session Breakout）模型下的EAS发现机制，并解读动态PSA分布（Dynamic PSA Distribution）这一高级应用，揭示5G网络如何实现按需、动态地构建通往边缘的“VIP通道”。

在上一篇的探讨中，我们看到“智行一号”在一条为它预设的“VIP专用通道”（分布式锚点模型）上，实现了高效的EAS发现与重发现。这种模型简单直接，但它要求整个PDU会话完全本地化。然而，在现实世界中，“智行一号”的任务是复杂的，它既需要与本地的交通信号灯进行毫秒级的低时延交互（边缘业务），也需要向远在千里之外的总部数据中心上报日志、下载更新（普通互联网业务）。

如果为这两类业务分别建立PDU会话，会增加信令和终端的开销；如果都使用分布式锚点，又会导致普通业务的路由次优。那么，能否在同一个PDU会话中，智能地让不同业务“各行其道”呢？

这正是**会话分离（Session Breakout）**模型所要解决的核心问题。它堪称5G边缘计算架构的“皇冠明珠”。而本章将要解读的流程，正是这颗明珠上最璀璨的光芒——它揭示了一个革命性的范式：边缘服务的发现过程，本身就成为了动态创建边缘连接路径的触发器。 让我们再次跟随“智行一号”，看它如何通过一次简单的DNS查询，为自己变魔术般地开辟出一条直达边缘的捷径。

1. 会话分离模型：高速公路上的“动态VIP出口”

在深入流程细节前，让我们再次形象地理解一下会话分离模型。

想象一条国家级高速公路，代表着UE的PDU会話。默认情况下，所有车辆都驶向一个遥远的“国家级交通枢纽”（C-PSA UPF），从那里再分发到全国各地。这条高速公路沿途经过许多城市，每个城市都有一些独特的“本地景点”（EAS），这些景点由一些本地的“小型出口”（L-PSA UPF）连接。

在传统模式下，这些本地出口是关闭的。而会话分离模型，则是在高速公路上安装了一套智能交通系统。当系统识别到一辆持有“本地景点VIP通行证”的车辆（发往EAS的数据包）时，它会动态地为这辆车打开距离景点最近的那个小型出口，并引导它下去。而其他普通车辆则不受影响，继续在主路上行驶。

这个“智能交通系统”的核心，就是我们接下来要详细解读的、由EASDF和SMF联袂上演的发现流程。

2. 6.2.3 EAS (Re-)discovery over Session Breakout Connectivity Model (会话分离模型下的发现流程)

这是本规范最核心的流程之一，它完整地展示了从一次DNS查询，到最终建立本地分流路径的全过程。我们将重点剖析其子章节6.2.3.2.2 EAS Discovery Procedure with EASDF，并通过Figure 6.2.3.2.2-1这张时序图来一步步分解。

场景设定

“智行一号”正在城市的快速路上行驶。它建立了一个标准的PDU会话，该会话的锚点位于运营商核心机房的C-PSA UPF。现在，它需要启动AI视觉辅助驾驶功能，该功能需要连接到部署在路边边缘机房的EAS aivision.operator.com。

步骤1 & 2: PDU会话建立 & EASDF选择 (Figure 6.2.3.2.2-1, Step 1 & 2)

  1. UE sends PDU Session Establishment Request… The SMF retrieves the UE subscription information…
  1. During the PDU Session Establishment procedure, the SMF selects EASDF… The SMF may indicate to the UE either that for the PDU Session the use of the EDC functionality is allowed or that for the PDU Session the use of the EDC functionality is required.

  • 深度解析：

    • 初始状态： “智行一号”发起PDU会话建立请求。SMF根据签约数据和网络策略，为其建立一个默认锚定在C-PSA的会话。这意味着，此时此刻，所有流量都将走向核心网。

    • 指定导航员： 在这个过程中，SMF会通过NRF为这个会话选择一个合适的EASDF。然后，它通过PCO将这个EASDF的IP地址下发给“智行一号”，并可能强制要求其使用EDC功能。

  • 此刻的状态： PDU会话已激活，但它是一条标准的“高速公路”，还没有任何通往边缘的“本地出口”。“智行一号”已经知道了它的“边缘服务专属导航员”（EASDF）的联系方式。

步骤3 & 4: 创建DNS上下文 (Figure 6.2.3.2.2-1, Step 3 & 4)

  1. The SMF invokes Neasdf_DNSContext_Create Request (UE IP address, DNN, notification endpoint, (DNS message handling rules)) to the selected EASDF.
  1. The EASDF invokes the service operation Neasdf_DNSContext_Create Response…

  • 深度解析： 在把EASDF地址告诉UE之后，SMF会先主动去和EASDF“打个招呼”，为这个PDU会话创建一个**“DNS上下文”**。

  • 这个上下文就像SMF在EASDF那里为“智行一号”建了一个专属档案袋。档案袋里存放着关键信息：

    • UE IP地址： “智行一号”的身份标识。

    • Notification endpoint： SMF的“回调地址”。当有需要报告的事件发生时，EASDF知道该通知谁。

    • DNS消息处理规则： 这是最重要的内容，是SMF下发给EASDF的“行动指南”。例如，规则可能是：“如果‘智行一号’查询任何.operator.com结尾的域名，请立刻通知我。”

  • 为何需要这一步？ 这一步至关重要，它将EASDF从一个被动的DNS服务器，变成了一个主动的、为SMF服务的网络事件探测器。SMF通过预设规则，让EASDF成为了它安插在DNS路径上的“哨兵”。

步骤 7-9: 发现的火花 - DNS查询与报告 (Figure 6.2.3.2.2-1, Step 7, 8, 9)

  1. …the Application in the UE uses the EDC functionality… to send the DNS Query to the EASDF.
  1. If the DNS Query message matches a DNS message detection template… the EASDF sends the DNS message report to SMF by invoking Neasdf_DNSContext_Notify Request…
  1. The SMF responds with Neasdf_DNSContext_Notify Response.

  • 深度解析：

    • 触发： “智行一号”的AI视觉应用启动，通过EDC向EASDF发起了对aivision.operator.com的DNS查询。

    • 匹配与报告： EASDF收到了查询。它立刻翻阅“智行一号”的“档案袋”，发现这个查询完美匹配了SMF预设的规则。于是，这个“哨兵”立刻拉响了警报，向SMF的“回调地址”发送了一个Notify通知：“报告！‘智行一号’正在查询边缘服务aivision.operator.com！”

  • 此刻的状态： DNS查询本身还没有被解析。但这次查询行为，已经像一颗投入平静湖面的石子，在核心网的控制面激起了涟漪。SMF已经被激活，知道了UE的服务意图。

步骤 12-15: 后端解析与再次报告 (Figure 6.2.3.2.2-1, Step 12, 13, 14, 15)

  1. The EASDF handles the DNS Query message received from the UE… sends it to C-DNS server
  1. EASDF receives the DNS Response including EAS IP addresses…
  1. The EASDF sends DNS message reporting to the SMF by invoking Neasdf_DNSContext_Notify request including EAS information… Per the received DNS message handling rule, the EASDF does not send the DNS Response message to the UE but waits for SMF instructions… i.e. buffering the DNS Response message.

  • 深度解析：

    • 在向SMF报告的同时，EASDF会将原始的DNS查询转发给后端的DNS系统（如C-DNS或权威DNS）进行实际的解析，并拿到了aivision.operator.com对应的EAS IP地址。

    • 现在，EASDF掌握了更关键的信息——目的地。它再次向SMF发送Notify报告：“补充报告！‘智行一号’想去的aivision.operator.com，具体的IP地址是21.34.56.78。”

    • 关键动作 - 缓冲（Buffering）： 根据SMF下发的规则，EASDF此时并不会立即将这个IP地址返回给“智行一号”。它会将这个DNS响应缓冲起来，扣在自己手里。

  • 为何要缓冲？ 这是整个流程的神来之笔。如果EASDF立刻返回IP，UE就会马上向这个IP发送数据。但此时，通往这个IP的“本地出口”还没有建好，数据流仍然会走向C-PSA，导致次优路由。缓冲DNS响应，就是为了给SMF争取宝贵的“施工时间”，来建立本地分流路径。

步骤 16: 网络的魔法 - 建立本地分流路径 (Figure 6.2.3.2.2-1, Step 16)

  1. The SMF may perform UL CL/BP and Local PSA selection and insert UL CL/BP and Local PSA. Based on EAS information received from the EASDF…, the SMF may determine the DNAI. The SMF may perform UL CL/BP and Local PSA selection and insertion as described in TS 23.502.

  • 深度解析： SMF现在掌握了所有必要信息：谁（“智行一号”）、要去哪里（EAS IP地址）、当前在哪里（UE的位置信息）。于是，它开始执行真正的“会话分离”操作：

    1. 决策： SMF根据EAS的IP地址，反向查询或推断出这个EAS所属的DNAI（数据网络接入标识符），即它位于哪个本地数据网络。

    2. 选址： SMF选择一个靠近“智行一号”当前位置、并且能够高效接入该DNAI的UPF，作为L-PSA。

    3. 施工： SMF向路径上的UL CL UPF（可能就是C-PSA本身）下发N4规则，指令内容是：“建立一条新的转发规则：所有目标地址为21.34.56.78的数据包，全部转发到新选择的L-PSA去。”

  • 此刻的状态： 在“智行一号”毫不知情的情况下，5G网络已经在其行驶的“高速公路”旁，为它悄悄地建好了一个直达目的地的“VIP专用出口”。

步骤 17-19: 绿灯放行 (Figure 6.2.3.2.2-1, Step 17, 18, 19)

  1. The SMF invokes Neasdf_DNSContext_Update Request (DNS message handling rules). The DNS message handling rule with the Control Action “Send the buffered DNS response(s) message to UE” indicates the EASDF to send DNS Response(s) buffered…
  1. …the EASDF sends the DNS Response(s) to the UE…

  • 深度解析： “VIP出口”建好后，SMF向EASDF发送了一条Update指令，更新了之前的处理规则：“行动指南更新：现在，请把你手里扣着的那个给‘智行一号’的DNS响应，发给它。”

  • EASDF收到指令后，立刻将缓冲的DNS响应（包含EAS IP 21.34.56.78）发送给“智行一号”。

  • “智行一号”的应用拿到了IP地址，开始发送AI视觉数据流。这些数据包到达UL CL后，被新建立的N4规则精确匹配，顺着新建的“VIP出口”L-PSA，瞬时抵达了路边的EAS。

  • 一次完美的、由DNS查询触发的动态会话分离宣告完成。

3. 6.2.2.4 动态PSA分布：从中央高速到本地高速的“主路切换”

动态PSA分布（Dynamic PSA distribution）可以看作是会话分离模型的一个高级且强大的变种。

5GC supports an EAS discovery procedure that allows that at PDU Session Establishment the SMF selects a Central PSA, regardless if a Local PSA is available… and then, it allows to dynamically re-anchor the PDU Session and transition to a Distributed Anchor Point connectivity model when needed.

  • 深度解析：

    • 初始状态： 为了节省资源和简化初始建立流程，一个PDU会话开始时，总是被锚定在C-PSA，即使UE所在的位置有可用的L-PSA。这就像“智行一号”无论在哪里，启动后总是先开上“国家高速”。

    • 触发器： 触发器与之前完全相同——UE发起了第一次访问边缘服务的DNS查询。

    • 网络动作的升级： SMF收到EASDF的报告后，它做出的决策不再是仅仅为这一个EAS IP“开一个旁路（UL CL）”，而是做出一个更宏大的决定：“既然‘智行一号’已经开始在这个区域执行边缘任务了，那么它接下来的所有活动，很可能都是本地化的。我决定，将它整个PDU会话的主锚点，从中央的C-PSA，通过SSC Mode 2/3的无缝切换流程，整体迁移到一个本地的L-PSA上！”

  • 结果： 经过这次“重锚定”，PDU会话的连接模型，从一个标准的中央锚点模型，动态地转变成了我们上一章讨论的分布式锚点模型。

  • 场景代入(“智行一号”)： “智行一号”从总部出发，PDU会话锚定在总部的C-PSA。当它行驶进入汉堡港作业区，并第一次请求连接港区调度EAS时，SMF触发了动态PSA分布。它的整个会话被无缝地切换到了汉堡港的L-PSA上。从此以后，它在这个港区内的所有通信（包括访问其他本地EAS，甚至访问互联网），都将通过这个本地的L-PSA进行，获得了全局的低时延优势。

4. 总结：从静态路径到动态智能

通过对会话分离模型下EAS发现流程的深度剖析，我们见证了5G边缘计算最核心的智能化体现：

  • 变被动为主动： 网络不再是被动地为UE提供连接，而是通过EASDF这个“哨兵”，主动地探测UE的业务意图。

  • 按需建路： 通往边缘的优化路径不再是预先固定的，而是在UE真正需要它的一瞬间，由SMF根据实时信息动态地构建出来。这极大地提升了网络资源的利用效率。

  • 无感体验： 整个复杂的“建路”过程，通过巧妙地缓冲DNS响应，对上层应用和最终用户实现了完全的透明。用户体验到的，只是“更快了”。

  • 模型的演进： 动态PSA分布则展示了更高的网络智能，网络可以根据业务行为，动态地改变整个会话的“属性”，实现从“中央服务”到“本地服务”的宏观模式切换。

“智行一号”在城市的普通道路和高速公路上灵活穿梭，5G网络也通过会话分离模型，为它的数据流构建了同样灵活的虚拟路径。这正是“软件定义网络”（SDN）思想在5G核心网中最生动的实践之一。

FAQ环节

Q1：EASDF缓冲DNS响应，如果SMF“施工”时间太长，UE会不会因为DNS超时而重试？

A1：这是一个很好的问题，涉及到流程的健壮性。3GPP规范定义的是逻辑流程，具体的超时时间由实现和网络配置决定。运营商在部署时，会确保EASDF与SMF之间的信令交互、以及SMF配置UPF的N4接口时延，都远小于常规的DNS查询超时时间（通常是秒级）。整个后台“施工”过程是在毫秒级完成的，因此在正常情况下，UE不会感知到超时。如果发生异常（如SMF过载），UE的DNS重试机制本身也为流程提供了一定的容错能力。

Q2：这个流程对EASDF和SMF的性能要求是不是非常高？

A2：是的。EASDF不仅要处理大量的DNS查询，还需要与SMF进行实时的、事务性的API调用（创建上下文、通知、更新等）。SMF则需要能够快速响应EASDF的通知，并实时地对UPF进行N4接口的策略下发。这要求这些网元都必须具备高性能、低时延的处理能力，并且它们之间的接口必须是高效和可靠的。这也是为什么5G核心网采用云原生、服务化的架构，以支持这种弹性和高性能的需求。

Q3：动态PSA分布和会话分离（UL CL）有什么根本区别？我该如何选择？

A3：根本区别在于影响范围。会话分离（UL CL）是“微创手术”，它只针对特定的、已知的边缘业务流（基于EAS IP地址）开辟一条旁路，PDU会话的主锚点和UE IP保持不变，影响范围小而精确。而动态PSA分布是“主干道切换”，它改变了整个PDU会话的锚点，会话之后的所有流量（无论新旧，无论边缘还是互联网）都将通过新的本地锚点路由，可能会导致UE IP前缀的改变，影响范围是全局的。

选择依据： 如果一个UE的业务模式是“大部分时间访问互联网，偶尔访问几个边缘服务”，那么会话分离更合适。如果UE一旦进入某个区域，其绝大部分业务都会变为本地化的边缘业务（如“智行一号”进入港区），那么动态PSA分布一次性地将其“本地化”会更高效。

Q4：如果“智行一号”的AI视觉应用使用加密DNS（DoH/DoT），这套流程还能工作吗？

A4：这是一个致命挑战。如果应用使用端到端的加密DNS，将DNS查询封装在HTTPS或TLS流量中，那么路径上的EASDF将无法看到DNS查询的明文内容，也就无法匹配SMF下发的规则，整个由DNS查询触发的机制就会失效。这是当前5G边缘计算标准方案与互联网隐私技术发展趋势之间的一个主要矛盾点。要解决这个问题，可能需要UE操作系统层面的配合，或者应用主动与EDC功能进行交互。

Q5：在这个流程中，SMF是如何知道UL CL UPF和L-PSA UPF的地址并对它们进行配置的？

A5：这依赖于5G核心网的拓扑管理和NF选择功能。所有的UPF（包括它们的类型、地理位置、支持的DNAI等能力）都会在NRF中注册。当SMF需要选择一个UL CL或L-PSA时，它会向NRF查询，找到符合条件的UPF实例。一旦选定，SMF就知道该UPF的地址，并通过标准的N4接口（基于PFCP协议）向其发送会话建立/修改请求，将所需的转发规则（PDR、FAR等）配置下去。

关系图谱