深度解析 3GPP TS 28.552：5.1.1.3 UE throughput (Part 1 - 揭秘用户速率体验的测量之道)

本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中，关于“5.1.1.3 UE throughput”的核心章节（5.1.1.3.1至5.1.1.3.4），旨在为读者提供一个关于5G用户速率体验测量方法的深度剖析。

引言：网红Vlogger“安娜”的5G“翻车”现场

“王哥，紧急投诉！你看这个！” 网优中心，小林将一个热门短视频投到大屏上。视频里，知名的科技Vlogger安娜正在一个新开业的“5G未来商城”做直播，背景里充满了科技感。

“哈喽，宝宝们！我现在就在号称全5G覆盖的未来商城，我们来测一下这里的网络到底有多‘未来’！”安娜热情地对着镜头说，她打开一款测速软件，屏幕上的数字一路狂飙，最终定格在“下行1.2Gbps”。“哇哦！速度 amazing！”

然而，尴尬的一幕很快发生。当她尝试将一段刚刚拍摄的4K视频素材上传到云盘时，进度条却走走停停，预估时间从“2分钟”跳到了“15分钟”。她的直播画面也开始出现马赛克和卡顿。“呃……看来这个5G的‘未来’，有时候也会堵车？”安娜略带调侃地对着卡顿的直播画面说。

视频的评论区炸开了锅，不少粉丝留言说自己也遇到过类似“测速猛如虎，一用变成二百五”的5G体验。老王看着眉头紧锁的小林，说道：“典型的‘峰值速率陷阱’。测速软件跑出来的，是网络在最短时间、最理想状况下的极限冲刺速度，而安娜上传视频，考验的是网络持续、稳定的‘长跑’能力。这两者完全是两码事。”

他调出TS 28.552，翻到了5.1.1.3节——UE throughput。“要弄清楚安娜的‘翻车’原因，我们就必须用3GPP这把最标准的尺子，去测量她真正的‘长跑’成绩。这一节，就是专门为衡量真实用户体验速率而设计的。它不关心一瞬间的峰值，只关心在一次完整的数据传输任务中，网络的平均表现如何。今天，我们就来解剖它，看看规范是如何科学、严谨地定义和测量用户速率的。”

这篇文章，我们将跟随老王和小林的分析，深入探讨UE吞吐率的测量原理，揭示为何我们手机上的感受，往往与测速软件的结果大相径庭。

1. 破碎的“峰值神话”：5.1.1.3.1 Average DL UE throughput in gNB (下行UE平均吞吐率)

“我们先来看安娜下载高清直播素材时的体验，也就是下行速率。”老王首先指向了5.1.1.3.1节。

a) This measurement provides the average UE throughput in downlink. This measurement is intended for data bursts that are large enough to require transmissions to be split across multiple slots. The UE data volume refers to the total volume scheduled for each UE regardless if using only primary- or also supplemental aggregated carriers. The measurement is optionally split into subcounters per QoS level… per supported S-NSSAI… and per BWP. c) This measurement is obtained according to the following formula based on the “ThpVolDl” and “ThpTimeDl” defined below. If ∑_UEs ThpTimeDl > 0, (∑_UEs ThpVolDl / ∑_UEs ThpTimeDl) * 1000 [kbit/s] For small data bursts, where all buffered data is included in one initial HARQ transmission, ThpTimeDl = 0, otherwise ThpTimeDl = T1 - T2 [ms]

1.1 深度解析：“长跑”成绩的计算公式

“小林，你看，规范开篇就强调，这个测量是为‘大到需要跨多个时隙传输的数据突发’设计的。这就是它和测速软件的根本区别，它关注的是持续性任务。”老王开始剖析这个看似复杂的测量方法。

要计算平均吞吐率，核心是两个变量：ThpVolDl (吞吐量) 和 ThpTimeDl (吞吐时间)。

1. ThpVolDl (Throughput Volume Downlink) - 到底传输了多少数据？

规范中定义ThpVolDl为：

The RLC level volume of a data burst, excluding the data transmitted in the slot when the buffer is emptied. A sample for ThpVolDl is the data volume, counted on RLC SDU level, in kbit successfully transmitted (acknowledged by UE) in DL for one DRB during a sample of ThpTimeDl.

“这里面有几个关键点，”老王逐一圈出：

• RLC SDU level: 统计的是RLC层的业务数据量，剔除了MAC层和物理层的各种头开销，更接近用户感知到的“有效载荷”。
• successfully transmitted (acknowledged by UE): 必须是手机确认成功收到的数据量才算数。这保证了测量的有效性。
• excluding the data transmitted in the slot when the buffer is emptied: 这是最精妙的一点！它排除了清空缓冲区的“最后一个包”的数据量。为什么要这么做？因为最后一个包发送后，我们无法准确知道它的传输时间（后面没有包了，无法计算间隔），包含它会严重扭曲时间计算的准确性。这体现了规范的严谨。

2. ThpTimeDl (Throughput Time Downlink) - 传输这些数据花了多长时间？

ThpTimeDl = T1 - T2，这个时间不是从第一个字节开始到最后一个字节结束那么简单。

• T2 (起点): The point in time when the first transmission begins after a RLC SDU becomes available for transmission, where previously no RLC SDUs were available for transmission for the particular DRB.

  • 解读： T2是数据突发（Data Burst）的开始时刻。它的触发点是：某个DRB（数据无线承承载）的发送缓冲区从“空”变为“非空”后，该DRB的第一个数据包开始进行首次传输的时刻。这标志着一次新的“长跑”任务开始了。

• T1 (终点): The point in time after T2 when data up until the second last piece of data in the transmitted data burst which emptied the RLC SDU available for transmission… was successfully transmitted, as acknowledged by the UE.

  • 解读： T1是数据突发的结束时刻。它的定义非常巧妙，是清空缓冲区的那个数据突发中，倒数第二个数据块被UE确认成功接收的时刻。

“所以你看，”老王总结道，“ThpTimeDl测量的实际上是从‘第一枪’响起到‘倒数第二名’冲线的总时长。ThpVolDl测量的则是这段时间内冲线的所有‘运动员’（数据块）的总量。用总量除以总时长，就得到了这次‘长跑’的平均速度。这就是一次吞吐率采样。”

1.2 场景化举例：安娜的4K素材下载之旅

安娜在直播中需要从云盘下载一个100MB的4K素材。这个下载任务构成了一次大的数据突发。

1. 比赛开始 (T2): t=0ms，下载请求发出，第一个数据块到达gNB的RLC发送缓冲区，并被立刻调度发送。T2被标记为0ms。
2. 持续传输: 网络持续以高速率发送数据块。
3. 比赛结束 (T1): 假设整个下载任务由100个数据块组成。在t=980ms时，第99个数据块被安娜的手机成功接收并确认。T1被标记为980ms。
4. 计算样本:
   • ThpTimeDl = 980ms - 0ms = 980ms。
   • ThpVolDl = 前99个数据块的总大小（假设为99MB）。
   • 本次下载的吞吐率样本 ≈ (99 * 8 * 1000) kbit / 980 ms ≈ 808 Mbps。

“这个808Mbps，就是安娜这次下载任务的真实体验速率，它远比测速的1.2Gbps更能反映实际情况。基站会对网络中成千上万次这样的‘长跑’任务进行采样，最后得出一个Average DL UE throughput。”

2. 透视体验波动：5.1.1.3.2 Distribution of DL UE throughput in gNB (下行UE吞吐率分布)

小林查看了安娜所在小区的DRB.UEThpDl（过滤了安娜的切片和业务类型），发现平均速率居然有350Mbps。“王哥，平均速率不低啊，为什么安娜还是觉得卡？”

“问得好。平均数会说谎。一个富翁和九个穷人的平均资产也是富翁。安娜的体验，可能就是被‘平均’了。所以，我们要看分布。”老王指向了下一个测量项。

a) This measurement provides the distribution of the UE throughput in downlink. c) Considering there are n samples during measurement time T… the measurement of one sample is obtained by the following formula… [公式同5.1.1.3.1] d) A set of integers, each representing the (integer) number of samples with a DL UE throughput in the range represented by that bin.

2.1 深度解析与场景应用

这个测量项的原理很简单：对每一次计算出的吞吐率样本（比如刚才安娜的808Mbps），不再是用于累加求平均，而是将其归入一个预设的速率区间（bin）。

例如，速率区间（bin）设定为：

• Bin 1: 0 - 50 Mbps
• Bin 2: 50 - 200 Mbps
• Bin 3: 200 - 500 Mbps
• Bin 4: > 500 Mbps

小林调出了DRB.UEThpDlDist.Bin的分布图，真相大白：

• Bin 1 (0-50 Mbps): 1500个样本
• Bin 2 (50-200 Mbps): 800个样本
• Bin 3 (200-500 Mbps): 5000个样本
• Bin 4 (>500 Mbps): 2700个样本

“王哥，我明白了！”小林指着图表，“虽然有大量样本（2700+5000）的速率很高，拉高了平均值，但也有相当一部分（1500+800）的下载任务，其实际体验速率非常低，甚至低于50Mbps！安娜在直播时，很可能就是碰上了这部分低速率的‘倒霉’时刻，导致了卡顿。”

通过分布图，团队精准地定位了问题：网络存在速率稳定性问题，而不是绝对的容量不足。后续的优化方向就明确了：需要排查是什么原因导致了这些低速率样本的出现，是瞬时干扰？是调度不公？还是切换抖动？

3. 上传之痛的度量：UL UE Throughput (5.1.1.3.3 & 5.1.1.3.4)

解决了下行的问题，老王将目光转向了安娜上传视频“翻车”的根源。

5.1.1.3.3 Average UL UE throughput in gNB 5.1.1.3.4 Distribution of UL UE throughput in gNB (测量方法与下行对称)

3.1 深度解析：上行与下行的对称之美

上行吞吐率的测量原理与下行完全对称，只是观察视角从gNB变成了UE。

• ThpVolUl: 在gNB侧成功接收到的、由UE发送的RLC SDU总量（同样排除清空UE缓冲区的最后一个包）。
• ThpTimeUl = T1 - T2:
  • T2 (起点): UE的上行缓冲区从空变非空后，第一个数据块被成功发送并被gNB接收的时刻。
  • T1 (终点): 整个数据突发中，倒数第二个数据块被gNB成功接收的时刻。

3.2 场景化举例：安娜的4K视频上传瓶颈

安娜尝试上传那段4K视频，这就是一次上行数据突发。

小林调出了DRB.UEThpUl和DRB.UEThpUlDist.Bin的数据。

• 平均速率 (Average): 只有可怜的30Mbps。
• 速率分布 (Distribution): 超过90%的采样点都落在了“0-50 Mbps”这个最低的区间内。

“结果很明显了，”老王沉声说道，“安娜的上行体验非常糟糕，而且是持续性的糟糕，不是偶发。平均速率低，分布也集中在低速率区间。这说明现场的上行链路存在着严重的瓶颈。”

结合现场的其他指标，他们很快找到了原因：为了保障下行直播的高速率，现场的网络参数配置过于“偏心”，为下行分配了绝大部分的时隙资源和功率，导致上行信道资源严重不足。在调整了TDD时隙配比和上行功率控制参数后，安娜的上传速率得到了显著提升。

结论：透过速率看体验，用数据还原真实

“小林，记住今天安娜的案例。”在问题成功解决后，老王总结道，“用户的体验，不是一个简单的峰值速率数字能代表的。3GPP TS 28.552之所以设计出如此复杂的吞吐率测量方法，目的只有一个：尽可能真实地还原用户在执行持续性数据任务时的实际感受。”

通过对5.1.1.3节前四部分的学习，我们掌握了：

1. UE吞吐率是基于“数据突发”的统计测量， 关注的是“长跑”而非“百米冲刺”。
2. 精巧的T1/T2和数据量定义， 保证了测量结果的准确性和严谨性。
3. 平均值提供了宏观概览，但分布图才能揭示体验的稳定性， 两者结合才能全面评估网络性能。
4. 上行和下行同等重要， 必须对称地进行分析和优化。

然而，关于吞吐率的探索还未结束。那些被我们暂时忽略的“小数据包”怎么办？它们的体验又该如何衡量？这就是我们下一篇文章将要探讨的内容——“Unrestricted data volume”，敬请期待！

---

FAQ 环节

Q1：为什么规范要煞费苦心地定义T1和T2，并排除最后一个包，而不是简单地测量从第一个字节到最后一个字节的总时间？ A1：这是为了测量的精确性和可重复性。简单测量总时间会引入巨大的误差：1）无法确定第一个字节何时“应该”被发送，只能知道它何时“实际”被发送，这之间包含了调度延迟，会因网络负载不同而剧烈变化。2）最后一个包发送后，缓冲区变空，没有后续包可以用来计算传输间隔，无法准确界定其传输结束时间。规范的T1/T2定义，巧妙地将测量锚定在一次“数据突发”的持续传输阶段，排除了任务开始前的等待时间和任务结束时的不确定性，使得测量结果能更纯粹地反映网络在数据传输过程中的持续服务能力。

Q2：我的手机测速App显示1Gbps，但下载大文件只有100MB/s (约800Mbps)，这是否意味着网络“虚标”了？ A2：不完全是。测速App通常使用多线程、在最理想的信道和调度条件下进行短时测试，其结果接近于网络的“物理峰值速率”。而您下载大文件，是一个长时间、单线程（或有限线程）的任务，其速率更接近于TS 28.552定义的“UE吞吐率”。这个速率会受到当前小区的实际负载、调度策略、您的信道条件波动、以及服务器侧的限制等多种因素影响，因此通常会低于峰值速率。可以说，测速App展示的是“潜力”，而UE吞吐率测量的是“实战表现”。

Q3：什么是DRB (Data Radio Bearer)，为什么吞吐率测量是基于DRB的？ A3：DRB（数据无线承载）是UE和gNB之间为承载用户数据（IP包）而建立的一个逻辑通道。不同的业务类型（通过QoS区分）可能会映射到不同的DRB上。例如，语音业务可能走一个DRB，视频走另一个，普通上网又走一个。基于DRB进行测量，可以实现对不同业务承载的性能隔离分析。通过对特定DRB（及其关联的5QI）的吞吐率进行测量，我们就能知道特定业务（如安娜的视频上传）的实际速率体验，而不是所有业务混在一起的平均速率。

Q4：为什么上行吞吐率通常远低于下行？ A4：这主要由两方面原因决定。物理层设计上，大部分移动通信系统采用TDD（时分双工）或FDD（频分双工）技术，在频谱资源分配上，都会将更多的资源（时隙或带宽）分配给下行，因为普通用户的网络行为以下载为主。设备能力上，基站的发射功率、天线数量和处理能力远强于手机终端，这使得下行链路更容易实现高速率。因此，上行速率成为瓶颈是移动通信中的常态，这也是为什么对上行吞吐率的监控和优化尤为重要。

Q5：如果我的网络中存在大量的小包业务（如即时消息、心跳包），UE吞吐率这个指标还能有效评估它们的性能吗？ A5：UE吞吐率指标（Average/Distribution UE throughput）对评估这类“小数据突发”业务的性能是无效的。规范明确指出，这些测量“is intended for data bursts that are large enough to require transmissions to be split across multiple slots”，并且对于“all buffered data is included in one initial HARQ transmission”的小突发，其ThpTimeDl被记为0，不会计入最终的平均值计算。为了评估这类小包业务的性能，3GPP引入了后续章节的测量项，如5.1.1.3.5 Percentage of unrestricted DL UE data volume in gNB，我们将在下一篇文章中详细解读。