好的，我们继续本次的深度探索之旅。在前序文章中，我们已经系统性地梳理了NWDAF的架构、核心功能、高级协作机制以及标准服务接口。我们曾提到，规范中的某些重要章节因其内容的独立性和深度而被暂时“跳过”，留待专题解读。今天，我们将开启其中一个至关重要的篇章——数据网络性能分析，深入探索5G网络如何为边缘计算这一“杀手级”应用场景提供智能化的性能“导航”与“天气预报”。
深度解析 3GPP TS 23.288：6.14 DN Performance Analytics (数据网络性能分析)
本文技术原理深度参考了3GPP TS 23.288 V18.9.0 (2025-03) Release 18规范中，关于“6.14 DN Performance Analytics”的核心章节。本文旨在为读者详细剖析NWDAF如何对通往特定数据网络（尤其是边缘计算节点）的用户面路径进行性能分析与预测，这是保障低时延、高带宽边缘业务体验的核心技术。
5G时代的一大革命性变革，就是将计算和存储能力从遥远的云端，推向了离用户更近的网络边缘，这就是MEC（多接入边缘计算）。通过在基站附近部署应用服务器，可以极大地降低业务时延，为AR/VR、自动驾驶、工业控制等场景提供极致体验。
然而，边缘并非“法外之地”，它同样会面临拥塞、资源竞争和性能波动。一个应用部署在哪个边缘节点（DNAI - DN Access Identifier）？从哪个UPF路径访问它最优？当前路径的性能表现如何？未来半小时是否会变差？对这些问题的实时洞察和精准预测，是实现高质量边缘服务的关键。
数据网络性能分析 (DN Performance Analytics) 正是NWDAF“小慧”为解答这些问题而生的专属能力。她化身为一位专业的“边缘网络路径分析师”，为上层应用和网络功能提供通往数据网络的“实时路况”和“未来天气预报”。
场景设定：在一个庞大的智能制造工厂中，一套名为“鹰眼-AR”的增强现实远程专家指导系统正在运行。现场工程师戴上AR眼镜，远在总部的专家就能通过实时回传的高清视频和传感器数据，看到工程师的第一视角，并在其视野中叠加3D的维修指令图层。该系统对时延和带宽极为敏感，其应用实例被部署在工厂内的多个边缘计算节点（DNAI）上。工厂的智能调度平台（由一个AF代表）的核心任务，就是确保每位工程师的AR眼镜，始终连接到性能最佳的应用实例路径上。
1. “路径体检”：DN性能分析的服务内容 (TS 23.288 Clause 6.14.1)
工厂调度平台AF在向“小慧”请求“路径体检”时，可以提出哪些具体的需求？6.14.1节“General”对此进行了详细的定义。
This clause specifies how an NWDAF can provide DN Performance Analytics which provides analytics for user plane performance (i.e. average/maximum traffic rate, average/maximum packet delay, average packet loss rate) in the form of statistics or predictions to a service consumer.
“小慧”的核心任务是：分析和预测一条用户面路径上的性能，关键指标包括流量速率、包时延、丢包率。
1.1 三种不同的分析维度
The DN Performance Analytics may provide one or a combination of the following information:
- User plane performance analytics for a specific Edge Computing application … over a specific serving anchor UPF.
- User plane performance analytics for a specific Edge Computing application … over a specific DNAI.
- User plane performance analytics for a specific Edge Computing application … over a specific Edge Application Server Instance.
“小慧”可以从三个不同的维度来出具“体检报告”：
- 基于服务锚点UPF的性能：分析从某个特定的UPF（例如，服务于工厂一号车间的UPF-1）出发，到“鹰眼-AR”应用的端到端性能。
- 基于DNAI的性能：分析到某个特定的边缘节点（DNAI，可以理解为一个边缘数据中心）的路径性能。这是本场景的核心，AF需要比较到DNAI-1和DNAI-2的路径性能，以决定将应用实例部署在哪里，或者将用户流量路由到哪里。
- 基于应用实例的性能：分析到某个边缘节点上一个具体应用实例（由IP地址或FQDN标识）的性能。这可以帮助判断是路径问题，还是应用实例本身出现了性能瓶颈。
1.2 精细化的“体检申请单” (Analytics Filter Information)
Table 6.14.1-1 定义了AF在请求分析时可以提供的详细过滤参数。
表格用途解读与重绘:
Table 6.14.1-1: Analytics Filter Information related to DN Performance Analytics
| Information | Description |
|---|---|
| Application ID (0..max) | 要分析的应用标识，例如“鹰眼-AR”。 |
| S-NSSAI / NSI ID(s) | 应用所属的网络切片/切片实例。 |
| Area of Interest | UE所在的地理区域（TA列表）。 |
| Anchor UPF info | 指定的服务锚点UPF。 |
| DNN / DNAI | 指定的数据网络名或边缘节点标识。 |
| Application Server Addresses | 指定的应用服务器实例地址。 |
| List of analytics subsets | 希望获取的具体分析子集（如下行平均时延、上行峰值速率等）。 |
通过这张“申请单”，工厂调度平台AF可以提出非常精准的请求，例如：“请为我分析，在‘一号车间’区域（Area of Interest），所有使用‘鹰眼-AR’应用（Application ID）且属于‘uRLLC’切片（S-NSSAI）的用户，访问‘边缘节点DNAI-2’（DNAI）的下行平均包时延和上行峰值速率（analytics subsets）”。
2. “诊断依据”：DN性能分析的数据来源 (TS 23.288 Clause 6.14.2)
要出具一份权威的“路径体检报告”，“小慧”需要融合来自应用、网络和无线等多个领域的“诊断依据”。
2.1 来自AF的应用层“主观感受” (Table 6.14.2-1)
“鹰眼-AR”应用本身最清楚自己的运行状况。它会向“小慧”报告自己的“主观感受”。
表格用途解读与重绘:
Table 6.14.2-1: Performance Data from AF
| Information | Source | Description |
|---|---|---|
| UE identifier | AF | 发生测量的UE的IP地址。 |
| UE location | AF | 测量发生时UE的位置。 |
| UL/DL Performance Data | AF | 与UE和应用服务器通信会话相关的性能数据，包括：平均/最大包时延，平均/最大丢包率，平均/最小/最大吞吐率。 |
| Timestamp | AF | 测量的时间戳。 |
这份来自AF的数据，是业务层面的端到端（Glass-to-Glass）性能，是衡量用户体验最直接的黄金标准。
2.2 来自5GC NF的网络层“客观指标”
为了探究应用层性能背后的网络原因，“小慧”还需要收集来自核心网各NF的“客观指标”。规范在这里复用了Table 6.4.2-2（QoS流级别的网络数据），其中的关键数据包括：
- 来自SMF/UPF的
QoS flow Packet Delay: 测量从UE到PSA UPF之间的网络路径时延。 - 来自SMF的
5QI: 当前业务流的QoS等级。 - 来自AMF的
UE location: UE所在的无线小区位置。
这份数据是网络层面的路径性能，它帮助“小慧”区分问题是出在无线侧、核心网传输侧，还是应用服务器侧。
2.3 来自OAM的无线环境“天气图”
规范还引用了Table 6.4.2-3，允许“小慧”从OAM获取RAN侧的详细测量数据，如RSRP, RSRQ, SINR等。这些数据描绘了UE所处的无线环境“天气”，帮助“小慧”判断性能问题是否由无线信号差所导致。
数据融合的威力： “小慧”的专家能力，正体现在对这三类数据的融合分析上。
- 如果AF报告“时延高”，同时UPF也报告“路径时延高”，而OAM报告“无线信号良好”，那么问题很可能出在核心网或承载网上。
- 如果AF报告“时延高”，但UPF报告“路径时延低”，而OAM报告“无线信号差”，那么问题就很可能出在“最后一公里”的无线覆盖上。
3. “体检报告”：DN性能分析的输出 (TS 23.288 Clause 6.14.3)
在综合所有“诊断依据”后，“小慧”将出具一份详尽的“体检报告”，分为统计和预测两类。
3.1 DN性能统计 (Table 6.14.3-1)
这份报告总结了“过去一段时间”的路径性能。
表格用途解读与重绘 (节选):
Table 6.14.3-1: DN service performance statistics
| Information | Description |
|---|---|
| DN performance (0-x) | 针对该应用的DN性能列表 |
| > DNAI / Anchor UPF info / App Server… | 性能分析的维度（DNAI, UPF或应用实例） |
| > Performance | 性能指标 |
| >> Aggregated Traffic rate | 聚合流量速率（针对UE群组） |
| >> Average Packet Delay | 平均包时延（可分UE群组或单个UE） |
| >> Maximum Packet Loss Rate | 最大丢包率 |
| >> Number of UEs | 在该DNAI上使用该应用的UE数量 |
| > Spatial Validity Condition | 该统计适用的地理范围 |
报告解读：工厂调度平台AF可能会收到这样一份报告：“统计报告：在过去的1小时内，访问‘边缘节点DNAI-2’的‘鹰眼-AR’应用，平均包时延为18ms，峰值丢包率为0.01%，共有32名工程师在使用。”
3.2 DN性能预测 (Table 6.14.3-2)
这份报告着眼于“未来”，是实现主动式、预测性网络优化的关键。其结构与统计报告类似，但所有指标都变成了预测值，并增加了置信度(Confidence)。
报告解读：AF收到一份紧急预警：“预测报告：预计在未来10分钟，由于二号生产线启动大批量数据上传任务，访问‘边缘节点DNAI-2’的路径平均时延将上升至45ms，峰值丢包率可能达到1%。此预测的置信度为95%。”
4. “智能决策”：DN性能分析的流程与应用 (TS 23.288 Clause 6.14.4)
Figure 6.14.4-1: Procedure for NWDAF providing DN Performance analytics for an Application 描绘了从请求到智能决策的完整闭环。
-
AF发起订阅: 工厂调度平台AF向NWDAF订阅“鹰眼-AR”应用在DNAI-1和DNAI-2上的DN性能预测。
-
NWDAF多源数据采集: “小慧”启动数据采集：
- 2a: 向“鹰眼-AR”应用服务器（AF）订阅应用层的性能数据。
- 2b: 向核心网（SMF/UPF, AMF, OAM等）订阅网络层和无线层的性能数据。
-
NWDAF分析与预测 (2c): “小慧”融合所有数据，持续更新其对两条路径的性能画像和预测模型。
-
NWDAF提供预测报告 (3): “小慧”将预测结果（如“DNAI-2路径即将劣化”）主动通知给工厂调度平台AF。
-
AF执行智能决策:
If the analytics consumer is an SMF, the SMF may use the analytics to determine the UPF and DNAI that offers the best user plane performance. If the analytics consumer is an AF, the AF may use the analytics to determine the DNAI that has the best user plane performance if Application Server relocation is required.
收到预警后，工厂调度平台AF立即做出智能决策：
- 应用重定向/迁移: 指示一位正准备连接到DNAI-2的新工程师，将其流量重定向到当前性能更优的DNAI-1。
- 通知SMF/PCF: AF还可以通知SMF/PCF，请求网络层面配合进行流量疏导（例如，通过不同的UPF路径绕开拥塞点）。
通过这个闭环，系统实现了从“被动响应”到“主动预测”，从“尽力而为”到“智能择优”的巨大飞跃，确保了“鹰眼-AR”这类严苛应用的极致体验。
FAQ - 常见问题解答
Q1：DN性能分析和QoS可持续性分析(6.9 QoS Sustainability Analytics)有什么区别？ A1：这是两个不同维度但相关的分析。
- QoS可持续性分析 更关注无线侧，它预测的是在一个区域内，一个特定的**QoS等级（如5QI）**能否被持续满足。它回答的是“这个地方的无线网络能否撑得起这个QoS要求？”
- DN性能分析 更关注端到端的用户面路径，特别是核心网和数据网络（DN）侧。它分析的是一个具体应用流经特定UPF、到达特定DNAI或应用服务器的实际性能（时延、速率、丢包）。它回答的是“我这个应用，走这条路，体验好不好？” 两者可以结合使用，例如，QoS可持续性分析保证了“路面”（无线环境）是好的，DN性能分析则保证了“整条高速公路”（端到端路径）是通畅的。
Q2：为什么AF自己也要上报性能数据？它不是消费者吗？ A2：在这个分析中，AF扮演了双重角色。它既是分析结果的最终消费者，又是最重要的数据源之一。因为只有应用本身，才最清楚端到端的、用户感受最直接的性能（glass-to-glass latency）。网络侧（UPF, OAM）提供的数据是“客观指标”，而AF提供的是“主观体验”，将两者结合，才能做出最准确的判断。这体现了5G网络智能“网业协同”的设计思想。
Q3：NWDAF如何知道某个应用（如“鹰眼-AR”）部署在哪些DNAI或服务器上？ A3：这通常是通过配置或服务发现来完成的。
- 静态配置：在AF向NWDAF发起分析请求时，可以在
Analytics Filter Information中，通过Application Server Addresses或DNAI参数，明确告知NWDAF它关心的目标节点。 - 动态发现：AF可以将其服务实例信息注册到NRF中。NWDAF在需要时，可以向NRF查询“‘鹰眼-AR’这个应用都有哪些服务实例？它们分别部署在哪里？”，从而动态地获取分析目标。
Q4：这项分析对运营商有什么商业价值？ A4：商业价值巨大，是运营商在ToB（面向企业）市场，特别是MEC边缘计算领域的核心竞争力之一：
- 提供带SLA保障的MEC服务：运营商不再是仅仅提供“连接”，而是可以提供“有确定性性能保障的智能连接”。DN性能分析是实现和验证这份SLA承诺的关键工具。
- 智能调度与资源优化：通过对边缘资源的性能预测，运营商可以实现跨DNAI的智能负载均衡和应用调度，最大化资源利用率。
- 开放网络能力：可以将DN性能预测作为一项高价值的API，通过NEF开放给大型企业客户或应用开发者，让他们可以基于网络洞察来优化自己的应用逻辑，形成新的商业模式。
Q5：如果预测到性能即将劣化，除了将应用或流量迁移走，还有别的处理方法吗？ A5：还有多种协同处理方法：
- 网络侧主动保障：AF可以将预警信息通知给PCF/SMF。PCF/SMF可以为该应用流提升QoS等级，或为其在拥塞的UPF上预留专属资源，尝试在现有路径上“保障”其性能。
- 应用侧主动适应：“鹰眼-AR”应用收到预警后，可以主动降低视频回传的码率或分辨率，或者将3D维修指令从复杂的动态模型降级为静态图片，以适应即将变差的网络条件，保证核心功能的可用性。 这种网络与应用的“双向奔赴”，是实现真正智能、弹性业务体验的最高境界。