51学通信

深度解析 3GPP TS 29.552：5.7.18 E2E data volume transfer time analytics (端到端数据卷传输时间分析)

22分钟阅读

好的，我们继续深入探索TS 29.552规范，进入一个直接关系到用户对“快”最直观感知的分析领域——端到端数据卷传输时间分析。在前文中，我们已经从多个维度探讨了网络的性能与体验，而这项分析则聚焦于一个极其具体但又至关重要的用户体验指标：传输一个给定大小的文件，到底需要多长时间？

深度解析 3GPP TS 29.552：5.7.18 E2E data volume transfer time analytics (端到端数据卷传输时间分析)

本文技术原理深度参考了3GPP TS 29.552 V18.7.0 (2024-12) Release 18规范中关于“5.7.18 E2E data volume transfer time analytics”的核心章节，旨在为读者详细拆解NWDAF是如何扮演一位“网络测速大师”，通过对端到端路径的全链路分析，来预测传输一定量的数据所需的时间，从而为应用层的智能下载、视频码率自适应和网络优化提供关键决策依据。

前言：量化“网速快不快”的终极问题

“你的网速快吗？”——这是用户评价一个网络好坏最朴素、最核心的标准。然而，“快”是一个主观感受。传统的“测速软件”通过一次短暂的峰值速率测试，给出的“带宽”（如500Mbps）往往并不能完全代表用户在实际使用中的真实体验。

一个更贴近真实体验的问题是：“我下载一个1GB的电影，大概需要多长时间？” 要回答这个问题，不能只看瞬时的峰值带宽，还需要考虑：

  • 端到端的全路径性能: 瓶颈可能不在5G空口，而是在运营商的骨干网，或者在电影服务器所在的互联网链路上。

  • 网络的动态波动: 无线信号的抖动、网络负载的潮汐效应，都会导致传输速率在整个传输过程中是动态变化的。

  • 协议的影响: TCP协议的拥塞控制算法，会对实际的有效吞吐量产生巨大影响。

端到端数据卷传输时间分析（E2E data volume transfer time analytics）的使命，就是让‘洞察者’(Insight-AI)能够综合考虑上述所有因素，对这个“传输一个X大小的文件需要多久”的问题，给出一个科学的、预测性的答案。

这项分析的价值是巨大的：

  • 对于应用（AF）:

    • 视频App: 可以根据预测的传输时间，智能地选择最佳的初始缓冲大小和播放码率。

    • 应用商店: 可以在用户点击“下载”前，就给出一个更精准的“预计剩余时间”。

    • 云游戏: 可以判断当前网络是否能在规定时间内加载完下一个游戏场景的资源。

  • 对于网络（NF）:

    • PCF: 可以评估其QoS策略的实际效果，判断给予某个用户的50Mbps保障带宽，是否真的让他的下载时间缩短了。

在“未来科技博览会”上，一个高清视频服务商“4K-Universe”为了保障其VIP用户的观影体验，需要网络为其提供实时的“下载时间预测”。当用户点播一部4K电影时，“4K-Universe”的应用（AF）会向‘洞察者’发起请求：“我的VIP用户张三，在当前位置，要下载一个5GB的视频文件，请预测需要多长时间？”

本文将深入5.7.18节的信令流程，看看“网络测速大师”‘洞察者’是如何完成这次精准的“端到端耗时预测”的。

1. 任务简报：预测“最后一秒”的艺术

这项分析的目标是，为一个或一组UE，在特定的区域或路径上，预测传输一个给定数据量（Data Volume）所需的时间。

规范原文引用 (Clause 5.7.18 Introduction):

This procedure is used by the NWDAF service consumer (may be an NF e.g. AF or NEF) to obtain E2E (end-to-end) data volume transfer time analytics, which is calculated by the NWDAF based on the information collected from the AMF, SMF, UPF, AF, LCS via GMLC and/or OAM.

‘洞察者’解读道：“要精准预测一场‘长跑’（大文件传输）的耗时，我不能只看起跑瞬间的速度。我需要了解‘赛道’的全程状况——从‘起点’（用户手机）到‘终点’（应用服务器）的每一段路，以及‘赛道’上可能出现的各种干扰。”

  • 情报来源: 与QoS可持续性分析类似，这项分析也要求非常全面、端到端的数据。

    • AMF/GMLC: 提供UE的位置信息，因为无线环境是决定传输速率的第一道关口。

    • SMF/UPF: 提供用户面路径信息和实际的吞吐量数据。这是计算传输时间最直接的依据。

    • OAM: 提供更底层的RAN侧性能数据，如RAN吞吐量、RAN侧时延等。这有助于将端到端的时间，分解到不同的网段上。

    • AF: 应用服务器可以提供服务器侧的性能信息，例如服务器当前的出向带宽和负载情况。

  • 分析ID: E2E_DATA_TRANS_TIME (End-to-end data transfer time)

2. 行动方案：解构耗时预测的信令全流程

规范中的 “Figure 5.7.18-1: Procedure for E2E data volume transfer time analytics” 描绘了‘洞察者’进行这次预测的详细步骤。这个流程与我们之前探讨的QoS可持续性分析（5.7.11）在数据收集阶段有很高的相似性，但其分析目标和模型完全不同。

阶段一：任务启动与上下文建立 (步骤1 - 5)

“4K-Universe”的AF向‘洞察者’发起一次性的请求：“为用户张三，在当前位置，预测下行传输5GB数据所需的时间。”

步骤1a：AF发起请求

AF通过Nnwdaf_AnalyticsInfo_Request发起请求，analyticsId为E2E_DATA_TRANS_TIME，eventFilter中包含了supi、dataVolume (5GB)和direction (Downlink)。

步骤2a-5d：收集全链路上下文信息

‘洞察者’收到请求后，立刻启动了一系列并行的信息收集流程，以构建出完整的端到端视图。

  1. UE位置 (2a-3b, 10): 向AMF和GMLC请求UE的精确位置，以评估其当前的无线环境。

  2. 用户面路径 (4a-5d): 向SMF发起订阅，获取该PDU会话的用户面路径信息（特别是服务于该会话的UPF），并指示UPF开始上报性能数据。

阶段二：全链路性能“分段测速” (步骤6 - 11)

这是耗时预测的数据基础。‘洞察者’需要对从UE到AF的整条路径，进行“分段计时”。

步骤6-9d：来自AF的“服务器侧”性能

  • 动作: ‘洞察者’向“4K-Universe”的AF发起Naf_EventExposure_Subscribe订阅。

  • 目的: 获取应用服务器侧的性能。例如，AF可以告诉‘洞察者’：“我当前服务器出口带宽充足，不是瓶颈。”

步骤11：来自OAM的“RAN侧”性能

规范原文引用 (Step 11):

The NWDAF may collect RAN part delay for DL and UL per 5QI and S-NSSAI…, RAN Throughput for DL and UL…

  • 动作: ‘洞察者’向OAM请求RAN侧的性能测量数据。

  • 关键指标:

    • RAN Throughput: RAN侧能为该UE提供的实际吞吐量。这是空口瓶颈的直接体现。

    • RAN part delay: 数据包在无线段的传输时延。

来自UPF的“核心网与DN侧”性能

在步骤4-5中，‘洞察者’已经通过SMF，向UPF下发了性能上报规则。UPF会上报：

  • N6接口性能: UPF到数据网络（DN）的路径时延和吞吐量。

  • N3接口性能: UPF到基站的传输网性能。

阶段三：分析建模与“完赛时间”预测 (步骤12 - 21)

规范原文引用 (Step 12):

The NWDAF calculates the End-to-end data volume transfer time analytics based on the data collected from AMF, SMF, UPF, AF, LCS via GMLC and/or OAM.

所有“分段计时”的数据都已汇集。

  1. 瓶颈识别与有效吞吐量计算 (Step 12 & 20):

    • AnLF的“网络测速大师”开始分析。它将各个网段的性能数据进行比较，识别出整条链路的**“瓶颈（Bottleneck）”**。

    • 场景:

      • RAN侧可提供吞吐量：800Mbps

      • N3传输网容量：1Gbps

      • UPF处理能力：10Gbps

      • N6接口到DN性能：600Mbps

      • AF服务器出口带宽：1Gbps

    • 结论: 整条链路的端到端有效吞吐量（Effective Throughput），受限于N6接口，约为600Mbps。

  2. 考虑动态性与协议影响:

    • ‘洞察者’的AI模型会更进一步。它不仅看当前的瞬时瓶颈，还会结合历史数据和移动性预测：

      • 历史趋势: “该用户所在小区的负载，在接下来的10分钟内呈上升趋势，预计RAN侧吞吐量将下降到500Mbps。”

      • 移动性预测: “用户正走向一个信号覆盖较差的区域。”

      • TCP模型: 模型还会考虑TCP拥塞控制算法的行为，在网络抖动时，实际的应用层吞吐量会低于物理链路的容量。

    • 最终预测: 综合所有因素，模型给出一个动态的、加权的平均有效吞吐量预测，例如450Mbps。

  3. 计算传输时间:

    • 传输时间 = 数据卷 / 预测的平均有效吞吐量

    • 5GB * 8 / 450Mbps = (5 * 1024 * 8) Mb / 450 Mbps ≈ 91秒

  4. 交付预测报告 (Step 13 & 21): ‘洞察者’将这份精准的预测报告，通过_Request的响应，交付给“4K-Universe”的AF。

    • 报告内容: {"dataVolume": 5, "unit": "GB", "transferTime": 91, "unit": "seconds"}

闭环完成：“4K-Universe”的AF收到“预计耗时91秒”的预测后：

  1. 优化用户体验: 它可以在播放器界面上，自信地显示“正在缓冲，预计1.5分钟后开始播放”，而不是一个不准确的、跳来跳去的进度条。

  2. 智能码率决策: 如果91秒的缓冲时间超出了用户的可接受范围，AF可以主动做出决策，将请求的视频流从4K超高清，降级为1080P高清。1080P的视频文件可能只有1.5GB，根据同样的网络状况，预计的传输时间将大大缩短，从而实现“秒开”播放，保障了用户的观看连贯性体验。

总结：从“带宽”到“耗时”，更贴近体验的度量衡

5.7.18节的端到端数据卷传输时间分析，是NWDAF将网络性能分析与真实用户体验深度结合的又一个典范。它提供了一个比传统“带宽”测试更真实、更有用、更具可操作性的度量衡。

  • 端到端、全链路的真实写照: 它摒弃了只看“管道”某一段（如空口）的片面视角，通过对全链路的“分段测速”和“瓶颈分析”，给出了一个最接近用户真实下载体验的综合性评估。

  • 赋能应用层智能决策: 这项分析的直接价值，体现在对上层应用（AF）的赋能上。它为视频、下载、云游戏等流量密集型应用，提供了一个强大的“网络感知”工具，使其能够根据实时的、预测性的网络状况，动态地调整自身行为，从而在不确定的网络环境中，为用户提供最佳的、最稳定的服务体验。

  • 网络策略的“试金石”: 这项分析也可以被PCF等网络功能用来评估其策略的实际效果。例如，PCF为某个用户提升了QoS等级后，可以通过订阅这项分析，来量化地验证“用户的下载时间是否真的缩短了”，从而实现策略的闭环优化（Policy Assurance）。

端到端数据卷传输时间分析，让网络提供的“快”，不再是一个模糊的、广告语式的概念，而是一个可以被精准预测、量化管理、并最终服务于应用和用户体验的、实实在在的“承诺”。

在下一篇文章中，我们将继续5.7节的探索，转向一个更精细的流量分析领域——5.7.19 PDU Session Traffic Analytics (PDU会话流量分析)，看看‘洞察者’是如何对单个PDU会话的流量特征进行“微雕”画像的。

FAQ 环节

Q1：这项分析与QoS可持续性分析（5.7.11）非常相似，它们最核心的区别是什么？

A1：它们确实在数据收集层面高度相似，都强调端到端。但其分析目标和输出有着本质区别：

  • QoS可持续性分析: 回答的是“能 or 不能”的问题。它的输出是一个布尔型或状态型的结论：“在未来X分钟内，能否持续满足一组严格的QoS参数（如时延<5ms, 丢包率<10⁻⁵）？”它关注的是过程的稳定性和对SLA的符合性。

  • E2E传输时间分析: 回答的是“多久”的问题。它的输出是一个数值型的预测：“传输Y GB的数据，需要多长时间？”它关注的是结果的时效性和对吞吐量的综合评估。

可以理解为，前者是“质保专家”，后者是“工期预算师”。

Q2：这项分析能否用于上行传输时间的预测？

A2：可以。规范明确指出，消费者在发起请求时，可以通过direction参数来指定是DOWNLINK、UPLINK还是UPLINK_AND_DOWNLINK。对于上行传输，分析的逻辑是相同的，只是瓶颈点可能会有所不同。例如，上行的瓶颈通常更容易出现在无线空口的上行链路（用户手机的发射功率、上行干扰等），而不是服务器侧。NWDAF的模型会根据不同的方向，调用不同的数据集和权重来进行预测。

Q3：如果端到端路径上包含了互联网，NWDAF如何分析它无法控制的互联网部分的性能？

A3：这是一个核心挑战。NWDAF确实无法“看到”互联网内部的每一个路由器。但它可以通过**“黑盒测试”**的方式来评估互联网段的性能：

  1. UPF作为探测点: UPF位于运营商网络和互联网的边界。UPF可以通过主动探测（如对应用服务器进行ping或TWAMP探测）或被动测量（如观察TCP RTT），来测量从UPF到应用服务器这段“黑盒”的往返性能。

  2. AF作为信息源: AF（应用服务器）可以上报它自己感知的来自不同运营商、不同区域用户的接入性能。

  3. 历史数据与模型: NWDAF可以利用历史数据，学习和建模不同互联网路径（如到不同云服务商、不同CDN节点的路径）在不同时间段的性能表现。

通过将这些信息与自己网络内部（RAN, Transport）的性能数据相结合，NWDAF就可以相对准确地估算出端到端的总性能，并定位瓶颈。

Q4：TCP协议本身有复杂的拥塞控制算法，NWDAF的预测模型会考虑这一点吗？

A4：一个优秀的NWDAF实现必须考虑TCP的行为。如果不考虑TCP，仅仅用物理链路的最低带宽来计算传输时间，结果会非常不准确。

  • TCP启动阶段: TCP的“慢启动（Slow Start）”和“拥塞避免（Congestion Avoidance）”算法，意味着传输速率不是一开始就达到最大值，而是一个逐步攀升的过程。

  • 丢包响应: 当网络发生丢包时，TCP会主动降低其发送速率。

NWDAF的高级模型会内置一个简化的TCP行为模拟器。它会根据从UPF/OAM收集到的时延和丢包率等网络状态参数，来模拟TCP窗口的增长和收缩，从而预测出一个更接近真实的应用层有效吞吐量，而不是物理层或链路层的吞吐量。

Q5：这项分析的实时性要求高吗？

A5：是的，这项分析通常是按需、即时触发的，对实时性要求较高。因为网络的性能是瞬息万变的，一个10分钟前的预测可能已经失去了价值。当用户点击“播放”或“下载”按钮时，AF会立刻发起一次性的AnalyticsInfo_Request。NWDAF需要在秒级甚至亚秒级内，完成数据收集、分析和响应，才能为AF的实时决策（如选择码率）提供有效的输入。这对其后台的数据管道和计算引擎的性能提出了很高的要求。

关系图谱