51学通信

深度解析 3GPP TS 23.548：6.3 & 6.4 & 6.6 网业协同的双向对话 (Part 4 - AF影响与网络开放)

23分钟阅读

好的，遵从指令。我们已经深入探讨了5G边缘计算的架构、核心实体，以及在不同模型下的发现与重发现流程。现在，我们将进入一个更激动人心的领域，探索网络与应用之间如何从“单向服务”走向“双向赋能”的智慧对话。

深度解析 3GPP TS 23.548：6.3 & 6.4 & 6.6 网业协同的双向对话 (Part 4 - AF影响与网络开放)

本文技术原理深度参考了3GPP TS 23.548 V18.9.0 (2025-03) Release 18规范中，关于“6.3 Edge Relocation”, “6.4 Network Exposure to Edge Application Server”以及“6.6 Support of AF Guidance to PCF Determination of Proper URSP Rules”等核心章节。本文旨在为读者揭示5G边缘计算体系中，“网”与“业”如何打破壁垒，建立起一套双向沟通的协同机制：应用功能（AF）如何主动“指挥”网络行为，以及网络如何将自身状态“汇报”给应用，从而共同实现业务体验的极致优化。

在之前的系列文章中，我们的主角“智行一号”更多地扮演了一个“被动接受者”的角色。5G网络像一个全知全能的“幕后之手”，根据“智行一号”的移动，为它安排好最优的路径，触发它进行服务器的重新发现。这套机制虽然智能，但本质上仍是网络主导的、响应式的。

然而，真正的智慧交通系统，需要的远不止于此。“智行一号”背后的**“云端大脑”——运营中心**，作为一个强大的应用功能（AF），它拥有全局的车辆调度信息、实时的城市交通态势、以及对自身服务器负载的精准监控。它希望能够：

  • 主动出击： 在预判到前方路段即将拥堵时，不等“智行一号”开过去，就主动要求5G网络将其业务切换到另一个路径更优的边缘节点。

  • 明察秋毫： 实时了解“智行一号”当前网络连接的“健康度”（如时延、抖动），以便动态调整AI视觉分析的算法精度和视频码率，在网络波动时保证核心安全功能不受影响。

  • 未雨绸缪： 为即将上线的“车辆编队行驶”功能，向网络“预订”一条具有超高可靠、超低时延特性的专用通道（网络切片）。

这些需求，正是5G边缘计算从“可用”迈向“好用”，从“网随云动”迈向“云网融合”的关键一步。TS 23.548的6.3, 6.4和6.6等章节，正是为实现这场“网络与应用的双向对话”而设计的。

1. 主动的“大脑”：应用功能AF如何“指挥”网络

这部分我们将看到，AF不再是一个只能被动部署服务的“租户”，而是成为了一个可以主动影响网络资源调配和策略制定的“高级玩家”。

1.1 AF触发的边缘重定位 (6.3.7 Edge Relocation Triggered by AF)

这是AF主动“指挥”网络最直接的体现。

The AF may invoke the AF request targeting an individual UE address procedure as described in clause 4.3.6.4 of TS 23.502, due to EAS relocation. The EAS relocation may be due to AF internal triggers e.g. EAS load balance or maintenance, etc. or due to UP path change notification from SMF. The AF may include the following information: Indication for EAS Relocation, target DNAI…

  • 深度解析：

    • 触发动机： 规范明确指出，AF触发重定位的动机是多种多样的，包括但不限于：

      • EAS负载均衡： A区的EAS计算资源紧张，AF决定将部分业务迁移到B区。

      • EAS维护： A区的EAS需要进行软件升级或停机维护。

      • 响应网络变化： AF收到了来自SMF的“UP路径变化通知”（我们将在下一节详述），得知UE的网络环境发生了变化，因此主动发起应用层的配合迁移。

      • 更智能的外部事件： （规范未明确列出，但逻辑上支持）“智行一号”的运营中心通过城市交通大脑得知，车辆预定行驶路径上的B区网络信号更佳，或者B区的EAS能提供更高级的协同驾驶服务，因此决定提前切换。

    • 指挥方式： AF通过NEF向PCF发起一个AF请求（Npcf_PolicyAuthorization_Create/Update或Nnef_TrafficInfluence_Create/Update）。这个请求就像一份“工作指令”，其中最关键的信息是**target DNAI**——明确告诉网络，它希望将这个UE的业务流量引导到哪个新的本地数据网络去。

  • 流程闭环：

    1. “智行一号”运营中心（AF）决定将业务从A区切换到B区。

    2. AF向NEF发送请求，指明UE为“智行一号”，并指定target DNAI为IDC-B（B区边缘机房）。

    3. 请求通过NEF到达PCF，PCF将其转化为策略，并更新给为“智行一号”服务的SMF。

    4. SMF收到策略更新后，执行我们在上一篇文章中学到的边缘重定位流程：选择B区的L-PSA，向UE发送**EAS rediscovery indication**，等待UE完成重发现后，更新UL CL的转发规则。

  • 关键转变： 在这个流程中，整个事件的发起者从SMF（响应UE移动）变成了AF（基于应用层智能）。网络从一个“决策者”变成了AF决策的“高效执行者”，完美体现了网业协同的主动性。

1.2 AF指导UE策略：URSP规则的生成 (6.6 Support of AF Guidance to PCF Determination of Proper URSP Rules)

如果说触发重定位是AF对“战术动作”的指挥，那么指导URSP规则的生成，则是AF对“战略布局”的影响。

An AF related with Edge computing may need to guide PCF determination of proper URSP rules. The guidance sent by the AF may apply to any UE or to a set of UE(s) e.g. identified by a Group Id.

  • 深度解析： URSP (UE Route Selection Policy) 是5G终端侧的“流量分类总开关”。它是一系列规则，告诉UE上的操作系统，哪个应用的流量，应该走哪个PDU会话。而PDU会话可以绑定到不同的网络切片（S-NSSAI）和数据网络（DNN）。因此，通过影响URSP，AF就能够间接地将自己的应用“绑定”到特定的网络能力上。

  • 指挥方式： AF向PCF提供“应用指导（application guidance）”。这份指导包含了两个核心部分：

    • 应用流量描述符 (Application traffic descriptor): 用来识别应用流量。例如，一个FQDN（platooning.autodrive.com）、一个IP三元组，或者一个OS App ID。

    • 路由选择描述符 (Route selection parameter): 指定了该流量期望的网络路径特征。最关键的就是S-NSSAI（指定一个网络切片）和DNN。

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

    1. 需求： “智行一号”即将上线“高精度车辆编队行驶”功能，该功能需要eMBB+URLLC混合特性的网络切片（S-NSSAI=X）来保证车间通信的低时延和视频数据的高带宽。

    2. AF行动： 运营中心（AF）向PCF提供指导：“对于所有访问platooning.autodrive.com的流量，请将它们引导至S-NSSAI为X的切片。”

    3. PCF决策 & SMF执行： PCF收到这份指导后，会结合用户的签约数据（该用户是否允许使用切片X）和运营商的策略，生成一条URSP规则。例如：“规则10：[流量描述：platooning.autodrive.com] → [路由选择描述：S-NSSAI=X]”。这条规则最终通过SMF下发给“智行一号”。

    4. UE执行： “智行一号”的操作系统收到此规则后，当编队行驶应用启动并访问域名时，OS会匹配到规则10，并自动选择（或发起建立）一个承载在切片X上的PDU会话来发送这些数据。

  • 战略意义： 通过这个机制，AF不再需要关心UE如何选择网络，而是通过一种“意图驱动”的方式，向网络声明自己的需求，由网络负责将这个“意图”转化为终端上可执行的策略。这为网络切片的商业化和应用的差异化服务保障铺平了道路。

2. 倾听的“感官”：网络如何向应用“汇报”状态

一场高效的对话，不仅需要一方能“说”，另一方也必须善于“听”。5G网络通过网络能力开放，赋予了应用一双能够洞察网络内部状态的“慧眼”。

2.1 网络能力开放：QoS监测结果的实时暴露 (6.4 Network Exposure to Edge Application Server)

对于像“智行一号”这样的实时应用，知道网络“通不通”是远远不够的，它需要知道网络“好不好”。

In this release, in order to expose network information timely to local AF, the L-PSA UPF may expose i.e. QoS monitoring results as defined in clause 5.33.3 of TS 23.501, to the local AF.

  • 深度解析： 这句话宣告了一个重大的能力开放：L-PSA UPF——这个处理边缘流量的第一跳网络设备，可以直接将其对业务数据流的QoS监测结果，暴露给本地的应用（AF/EAS）。

  • 监测什么？ TS 23.501中定义了UPF可以监测的多种指标，对于边缘计算最关键的是：

    • 下行/上行包延迟 (Packet Delay)

    • 包丢失率 (Packet Loss Rate)

  • 关键机制：绕开核心的直接汇报 (6.4.2.1 Usage of Nupf_EventExposure)

    …the L-PSA UPF notifies the QoS Monitoring event information to the AF (directly or via Local NEF). If the L-PSA UPF supports the Nupf_EventExposure_Notify service operation… the L-PSA UPF sends the Nupf_EventExposure_Notify to the Notification Target Address…

  • 深度解析： 传统的QoS上报路径是UPF → SMF → PCF → AF，这条链路长、时延高，不适用于实时反馈。

  • TS 23.548为此设计了一条“捷径”：UPF可以直接调用**Nupf_EventExposure_Notify服务，将监测报告直接发送给一个预先配置的通知目标地址 (Notification Target Address)**。这个地址，就是本地EAS或本地AF的地址！

  • 流程全景：

    1. 订阅： 运营中心（AF）通过NEF/PCF，为“智行一号”的AI视觉数据流订阅QoS监测事件，并设定阈值（如：“当上行时延超过20ms时通知我”），同时提供一个接收报告的URL（即通知目标地址）。

    2. 配置： PCF将这个订阅转化为策略，下发给SMF。SMF则通过N4接口，向为“智行一号”服务的L-PSA UPF下发一条包含监测和报告指令的规则。

    3. 监测与直接报告： L-PSA UPF开始对“智行一号”的视频流进行逐包监测。当它发现连续几个数据包的转发时延超过了20ms时，会立刻触发一个事件，并向AF提供的URL，发送一个包含详细信息的HTTP POST请求（Nupf_EventExposure_Notify）。

    4. 应用自适应： 部署在本地EAS中的运营中心代理（本地AF），收到这个通知后，立即做出响应：“网络时延抖动，有丢帧风险！” 于是它通过应用层信令通知“智行一号”：“立即切换到备用分析算法，并临时将视频分辨率从4K降至1080P！”

  • 价值所在： 这个基于事件驱动的、绕开控制面核心的快速反馈闭环，是实现应用级高可靠性、自适应体验保障的终极武器。它让应用不再“盲目”地信任网络，而是能够与网络进行实时的、基于数据的“健康对话”。

3. 协同的深度：AF自身的变更 (6.3.2 Edge Relocation Involving AF Change)

规范甚至考虑到了更深层次的协同：在边缘重定位过程中，不仅EAS变了，连“指挥官”AF本身都可能发生变更。

…where the (E)AS relocation also implies AF relocation i.e. AF instance change. … the target AF may invoke Nnef_TrafficInfluence_Create to deliver the relocation related information…

  • 深度解析： 想象一个大型应用，它在每个区域都部署了一个本地的AF实例，负责管理本区域的EAS资源。当“智行一号”从A区移动到B区时，不仅EAS要切换，对它进行管理的AF也应该从AF-A切换到AF-B。

  • 规范为此提供了机制，允许源AF（AF-A）在向网络发起的请求中，包含目标AF（AF-B）的信息。或者，在SMF通知AF-A路径即将变更后，AF-A可以与AF-B进行后台通信，完成“指挥权”的交接，再由AF-B向网络发起后续的指令。

  • 这体现了3GPP规范设计的深远考虑，它不仅定义了网络与AF之间的接口，也为AF之间的协同预留了空间，构建了一个可扩展的、分布式的应用管理架构。

4. 总结：从单向管道到双向智能体

通过对6.3, 6.4, 6.6等章节的联合剖析，我们见证了5G网络与边缘应用之间关系的根本性转变。它们不再是简单的“服务提供者”与“服务使用者”的关系，而是演变成了一个共生的、双向交互的智能系统。

  • 应用拥有了“话语权”： AF可以通过影响流量路由和URSP规则，将自己的业务意图和SLA需求，清晰地传达并注入到网络策略中，让网络“为我所用”。

  • 网络拥有了“感知力”： 网络可以通过事件暴露机制，将底层的、实时的QoS状态，精准地“汇报”给应用，让应用能够“因网制宜”，做出自适应调整。

这场精彩的“双向对话”，彻底打破了曾经横亘在CT与IT之间的“协同壁垒”。对于“智行一号”而言，这意味着它的安全性和效率，不再仅仅依赖于自身的车载计算能力，而是建立在一个能够听它指挥、并随时向它汇报的、高度协同的“车-路-云”智能网络之上。

FAQ环节

Q1：AF, EAS, NEF, PCF，这些角色在“网业协同”中是如何分工的？

A1：可以这样形象地理解：AF是“应用大脑”（如“智行一号”的运营中心），它提出业务需求。EAS是“应用肢体”（实际处理数据的服务器），它执行具体任务。NEF是“网络外交部”，是AF与5G核心网沟通的唯一、安全入口。PCF是“网络参谋部”，它接收来自NEF的“外交请求”，结合用户签约和运营商政策进行“会商”，制定出最终的策略。SMF则是“一线指挥官”，它执行来自PCF的策略，调动UPF等用户面资源来完成具体部署。

Q2：UPF直接向AF/EAS报告QoS，这是否存在安全风险？如何保证这个接口不被滥用？

A2：存在潜在风险，因此安全机制至关重要。首先，这个直接报告的“目标地址”是由AF通过NEF→PCF→SMF这条可信链路配置下去的，确保了报告的目的地是合法的。其次，UPF与AF/EAS之间的Nupf_EventExposure接口通信，通常会采用HTTPS等加密传输，并可能需要进行双向证书认证，确保通信双方的身份可信。NEF和PCF作为策略的入口，也会对AF的订阅请求进行严格的鉴权和授权，不是任何应用都能随意订阅网络内部信息。

Q3：AF指导URSP规则，和用户自己在手机里设置应用使用哪个SIM卡（PDU会话）有什么区别？

A3：用户手动设置是静态的、粗粒度的。而AF指导下的URSP是动态的、精细化的、网络感知的。例如，AF可以指导生成一条规则：“只有当UE位于A区域时，才将app_X的流量导向切片Y”。这种带有“地理围栏”的动态策略是用户手动无法实现的。更重要的是，URSP是由网络下发的权威策略，其优先级通常高于用户的本地设置，保证了运营商对网络资源和SLA的管控能力。

Q4：一个应用的开发者，需要自己部署AF、NEF这些复杂的网元吗？

A4：不需要。NEF、PCF、SMF等都是运营商网络内部的核心网元。应用开发者通常只需要扮演AF的角色。在实践中，开发者可能不是直接调用3GPP定义的底层API，而是通过运营商或云服务商提供的更高层的“网络能力开放平台”来与NEF交互。开发者在这个平台上，通过图形化界面或更友好的SDK，来描述自己的应用需求（如“我需要为我的游戏应用在高峰期申请20ms的时延保障”），平台再将这些业务语言翻译成底层的AF-PCF/NEF信令。

Q5：网络向应用暴露了这么多信息，会不会泄露运营商的内部网络拓扑等敏感数据？

A5：这是网络能力开放设计的核心关切点之一。NEF在其中扮演了关键的“脱敏”和“抽象”角色。网络暴露给AF的，通常是经过抽象的、与业务相关的信息，而不是底层的物理拓扑。例如，网络会告诉AF“UE当前连接路径的时延是25ms”，但不会告诉AF这条路径具体经过了哪些UPF、基站和路由器。同样，AF向网络提供target DNAI，也只是提供一个逻辑位置标识，而不是一个具体的机房坐标。通过这种方式，实现了信息价值的传递，同时保护了各自域内的信息安全。

关系图谱