深度解析 3GPP TS 28.552：5.1.1.3 UE throughput (Part 2 - 小包数据与缓冲吞吐率)
本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中，关于“5.1.1.3 UE throughput”的核心章节（5.1.1.3.5至5.1.1.3.7），旨在为读者提供一个关于5G小包业务性能及gNB内部缓冲效率的深度测量剖析。
引言：从“长跑”到“短跑”，安娜直播间的新挑战
在上一篇文章中，网络优化专家老王和小林成功解决了网红Vlogger安娜在5G未来商城上传大视频“翻车”的问题，通过分析UE吞吐率的平均值和分布，找到了上行链路的资源瓶颈。
然而，几天后，新的问题又出现了。安娜的团队反馈，在直播互动环节，观众发送的弹幕和礼物特效，在安娜的监控屏上总是有延迟，严重影响了她与粉丝的实时互动。“测速依然飞快，大文件上传也流畅了，可为什么这些小小的互动信息就是‘慢半拍’呢？”
老王看着一脸困惑的小林，笑道：“我们上次优化的，是网络的‘长跑’能力，好比是货运通道。但直播互动，是成千上万条‘短跑’信息，它们走的是‘快速客运’。我们之前用的UE throughput那把尺子，是量‘长跑’成绩的，它天生就看不见这些‘短跑选手’。今天，我们就得换一套更精密的仪器。”
他再次打开了TS 28.552，指向了5.1.1.3节中我们上次“跳过”的部分。“你看，5.1.1.3.5和5.1.1.3.6，‘Percentage of unrestricted DL/UL UE data volume’，这就是专门为这些‘短跑选手’——小数据包——设计的‘秒表’。而5.1.1.3.7，‘Average DL UE buffered Throughput per DRB’，则是一台‘X光机’，能透视基站内部调度缓冲区的健康状况，找出造成‘慢半拍’的根源。”
这篇文章，我们将继续跟随老王师徒，深入探索用户速率测量的另外两个重要维度：如何衡量小包业务的性能，以及如何评估gNB内部缓冲区的调度效率。
1. 被“平均”忽略的大多数：非受限数据量的测量 (5.1.1.3.5 & 5.1.1.3.6)
“小林，还记得我们上次怎么计算UE吞吐率的吗？”老王提问道。
“记得，是用一次数据突发中，除去最后一个包的总数据量，除以从第一个包开始传输到倒数第二个包被确认的总时间。”小林回答得很干脆。
“没错。那么问题来了，如果一次数据传输，比如一条弹幕，小到只需要一个传输块（TB）、一次HARQ传输就搞定了，它的‘吞吐时间’是多少？”
小林思考了一下，恍然大悟：“它的ThpTimeDl被定义为0，所以它根本不会被计入平均吞吐率的计算中！”
“正是如此！”老王肯定道，“对于网络来说，这些小包业务就像城市交通中的摩托车和行人，数量庞大，但传统衡量高速公路‘车流量’（吞吐率）的指标完全覆盖不到它们。为此，规范引入了‘非受限数据量’（Unrestricted Data Volume）的概念。”
5.1.1.3.5 Percentage of unrestricted DL UE data volume in gNB a) This measurement provides the percentage of DL data volume for UEs in the cell that is classified as unrestricted, i.e., when the volume is so low that all data can be transferred in one slot and no UE throughput sample could be calculated. c) For periods when no data is transferred at all Percentage Unrestricted Volume DL = 0, otherwise: Percentage Unrestricted Volume DL = (∑_UEs ThpUnresVolDl) / (∑_UEs (ThpUnresVolDl + ThpVolDl)) * 100
5.1.1.3.6 Percentage of unrestricted UL UE data volume in gNB (定义与下行对称)
1.1 深度解析：“短跑选手”在赛场上的占比
老王解释说：“既然无法测量这些‘短跑选手’的速度，我们就换个思路，测量它们的‘数量占比’。这个指标的核心思想是，看看在网络总的数据传输量中，有多大比例是由这些无法计算吞吐率的小数据包构成的。”
公式 (∑ ThpUnresVolDl) / (∑ (ThpUnresVolDl + ThpVolDl)) 非常清晰：
-
ThpUnresVolDl(Throughput Unrestricted Volume Downlink):The volume of a data burst that is transmitted in the slot when the buffer is emptied (which could be the only slot needed to transmit the data burst) and not included in the UE throughput measurement.
这个变量统计的就是那些因为太小而无法计算吞吐率的数据突发的总量。简单来说，就是所有“短跑选手”的总数据量。
-
ThpVolDl(Throughput Volume Downlink):The volume of a data burst, excluding the data transmitted in the slot when the buffer is emptied.
这个变量就是我们上一篇文章中已经熟悉的、用于计算平均吞吐率的“长跑选手”的数据总量。
所以，这个百分比的物理意义就是：（小包数据总量）/（小包数据总量 + 大包数据总量）。它反映了网络中业务模型的构成。
1.2 场景化举例：安娜直播间的流量构成分析
小林立刻调取了安娜所在小区的DRB.UEUnresVolDl（下行非受限数据量百分比）和DRB.UEUnresVolUl（上行非受限数据量百分比）指标。
- 上行 (
DRB.UEUnresVolUl): 高达 45%。 - 下行 (
DRB.UEUnresVolDl): 达到 30%。
“王哥，这个数字说明了什么？”
老王分析道：“上行占比45%，非常高！这意味着安娜直播时，网络中近一半的上行流量都来自于观众发送的弹幕、点赞、小礼物请求等小包数据。而我们上次的优化，主要针对的是她上传大视频这种大包业务。”
“下行占比30%，也说明基站需要频繁地将这些弹幕和礼物特效的小数据包推送给安娜的监控设备。”
“洞察：”老王总结道，“安娜直播间的业务模型，是典型的‘大包’（视频流）与‘小包’（信令互动）混合模型。小包业务占比极高，网络的优化策略必须兼顾两者。如果调度器为了保证视频流的吞吐率，将小包的调度优先级降低或合并发送，就会造成安娜感知到的‘互动延迟’。这个指标告诉我们，优化的重点需要从单纯提升‘带宽’，转向改善‘调度实时性’。”
这个指标就像一面镜子，照出了网络流量的真实构成，为后续的QoS策略和调度器参数优化指明了方向。
2. 深入调度核心：gNB-DU缓冲吞吐率的“X光” (5.1.1.3.7)
“我们现在知道了问题和‘小包调度’有关，但这还是有点笼统。调度问题具体出在哪一环？是CU（中央单元）到DU（分布单元）的F1接口堵了，还是DU本身的缓冲区管理有问题？”老王提出了更深层次的问题，“要回答这个，我们需要一台‘X光机’，直接透视DU的缓冲状态。这就是Buffered Throughput这个测量项的作用。”
5.1.1.3.7 Average DL UE buffered Throughput per DRB a) This measurement provides the average down link buffered UE throughput per DRB on NRCellCU. … This measurement is intended for throughput per UE and bearer independent of traffic patterns and packet size. The measurement is based on Desired buffer size communicated within DDDS from DU to CU UP… Initial buffering time in CU and on F1… is excluded. c) This measurement is obtained by the following formula for a measurement period: (∑ ThroughputVolume) / (∑ ThroughputTime) [kbits/s]
2.1 深度解析：一种全新的“间接测量法”
这是一个相对复杂的测量项，因为它不再是直接测量，而是基于gNB内部CU和DU之间的信令反馈进行估算。
1. 问题背景：CU与DU的分离
在5G的CU-DU分离架构中，CU-UP（用户面）负责处理PDCP层，它决定了要发什么数据。而DU负责RLC/MAC/PHY层，它根据无线信道好坏，实际决定了什么时候发、发多少。两者之间通过F1接口连接。如果CU-UP像消防栓一样拼命向DU送水（数据），而DU面前只是一个小水管（无线信道），那么DU的缓冲区就会溢出导致丢包。反之，如果CU-UP给水太慢，DU的缓冲区就会干涸，导致无线资源浪费和业务卡顿。
2. 解决方案：DDDS反馈机制
为了解决这个问题，3GPP引入了DDDS (Downlink Data Delivery Status) 机制。它就像是DU派往CU的一个“观察员”，DU会通过DDDS信令周期性地向CU-UP汇报：
- “报告CU！我这里的缓冲区还剩多少数据。”
- “根据当前的空口质量，为了保证数据能‘丝滑’地传给用户，我希望我的缓冲区里能时刻保持
Desired buffer size（期望缓冲大小）的数据量。”
3. “缓冲吞吐率”的巧妙计算
Buffered Throughput的核心就是利用这个Desired buffer size来反向推算出DU认为自己能达到的“可实现吞吐率”（Achievable Throughput）。
The Achievable DRB throughput is obtained as the “Desired buffer size for data radio bearer” as part of last DDDS feedback divided with the DDDS reporting period time interval.
可实现吞吐率 = DU上报的期望缓冲大小 / DDDS上报周期
然后，Buffered Throughput的ThroughputTime就不再是测量T1和T2的差值了，而是通过一个公式估算：
ThroughputTime = ThroughputVolume (一个数据突发的PDCP SDU总量) / 可实现吞D吐率
这个ThroughputTime的物理意义是：根据DU自己的“期望”，一个数据突发应该在多长时间内被处理完毕。
最后，缓冲吞吐率 = (∑ ThroughputVolume) / (∑ ThroughputTime)
这个最终结果，衡量的是CU-UP下发数据的速率与DU期望处理速率之间的匹配程度。
4. 关键信息点：时间戳与流程
为了更精确地计算，规范还通过Table 5.1.1.3.7-2 DRB (SA, NSA option 3a) 定义了一系列时间戳，并在Figure 5.1.1.3.7-1 Average DL buffered UE throughput per DRB中图示了整个流程。
- T0’: 新数据突发的第一个PDCP SDU到达CU。
- T1’: 第一个对应的PDCP PDU经过F1接口到达DU。
- T2’: DU的缓冲区被清空。
- ThroughputTime ≈ T2’ - T1’: 整个测量估算的
ThroughputTime，在逻辑上近似于数据在DU缓冲区的驻留时间。
这个测量排除了T0'到T1'之间的初始F1传输时延，因为它关注的是DU缓冲区的稳态工作性能，而非初始建链时延。
2.2 场景化举例：透视安娜直播间的“微观卡顿”
小林调出了DRB.PDCP.UEThpDl.QOS（按安娜直播业务的QoS过滤）的缓冲吞吐率数据。结果显示，这个值在150Mbps到600Mbps之间剧烈波动，非常不稳定。
“王哥，这个剧烈的波动说明了什么？”
老王解释道：“这说明DU上报的‘期望缓冲大小’非常不稳定。当无线信道好时，DU信心满满，上报一个很大的期望值，算出来的‘可实现吞”吐率’就高。当信道突然变差，它就立刻上报一个很小的值，‘可实现吞吐率’就骤降。”
“而我们的CU-UP的流控算法可能不够智能，没能及时根据DU的反馈来调整下发数据的节奏。这就导致在信道好的时候给的数据不够，浪费了机会；在信道差的时候给的数据又太多，造成DU缓冲区拥塞和时延增加。这种快慢不均的节奏，最终在安娜的直播画面上，就体现为一阵流畅、一阵卡顿的‘微观卡顿’（Jitter）。”
最终定位： 问题出在CU-UP到DU的流控策略与无线信道变化的适配性上。通过Buffered Throughput这台“X光机”，团队成功地将问题从宏观的“调度问题”，进一步聚焦到了微观的“CU-DU协同与缓冲区管理”层面。
结论：从宏观体验到微观诊断
通过对UE吞吐率测量（Part 2）的学习，我们补全了速率测量的完整拼图。我们不仅学会了如何衡量决定交互体验的“小包业务”，还掌握了如何透视gNB内部缓冲区的健康状况。
- 非受限数据量百分比 (
Percentage of unrestricted volume) 像一个“业务成分分析仪”，它告诉我们网络中“短跑”和“长跑”业务的比例，指导我们制定宏观的QoS和调度优化策略。 - 缓冲吞吐率 (
Buffered Throughput) 则像一台精密的“X光机”，通过DDDS反馈机制，间接测量了CU-DU之间的协同效率和DU缓冲区的稳定性，是诊断“微观卡顿”和Jitter问题的利器。
安娜的两次“翻车”经历，生动地展示了TS 28.552中不同测量项的价值。从平均速率到速率分布，从大包吞吐率到小包占比，再到内部缓冲吞-吐率，我们一步步深入，最终定位了问题的根源。这正是数据驱动的精细化网络优化的魅力所在。
FAQ 环节
Q1：为什么“非受限数据量”只统计百分比，而不直接测量它们的时延？ A1：因为对于单次传输就完成的“小包”来说，精确测量其端到端时延在基站侧非常困难且开销巨大。如上一篇文章所述，准确的时延测量需要清晰的起点和终点。小包的传输时间极短，且其延迟主要由调度等待时间决定，波动性极大。相比之下，统计其在总流量中的“占比”是一个更稳定、更具宏观指导意义的指标。它能清晰地反映出业务模型，帮助网络判断是应该优先优化“带宽”还是“响应速度”。
Q2：Average DL UE buffered Throughput per DRB这个指标和Average DL UE throughput in gNB有什么本质区别？
A2：本质区别在于测量视角和目的不同。
Average DL UE throughput是端到端体验视角，它测量的是数据从准备进入空口到被UE成功接收的实际平均速率，更贴近用户的真实感受，用于评估业务的最终交付效果。Average DL UE buffered Throughput是gNB内部调度器视角，它基于DU的反馈（DDDS）来估算DU的“期望处理能力”，并衡量CU的数据下发策略是否与之匹配，用于诊断gNB内部CU-DU间的流控和缓冲效率问题。前者看“结果”，后者看“过程”。
Q3：DDDS（下行数据分发状态）机制是强制开启的吗？如果没有DDDS，还能测量缓冲吞吐率吗？
A3：DDDS是gNB内部CU和DU之间的一个可选功能。如果没有开启DDDS，Average DL UE buffered Throughput这个测量项是无法计算的，因为其核心计算依据——“Desired buffer size”和“Achievable Throughput”——都来自于DDDS的反馈。在这种情况下，我们仍然可以通过分析更宏观的指标，如Packet Delay分布和UE Throughput分布，来间接推断可能存在的缓冲或调度问题。
Q4：Buffered Throughput测量为何要排除初始F1时延（T0’到T1’之间的时间）？
A4：这是为了测量的焦点分离。该测量的核心目标是评估DU在稳态运行下的缓冲管理和数据处理能力，即CU-DU之间的流控是否平滑。一个数据突发的第一个数据包到达DU的过程，包含了初始的路径建立和信令交互，这段“启动时间”并不能反映后续持续传输中的缓冲效率。排除它，可以让测量结果更纯粹地聚焦于数据在DU缓冲区内的“驻留和处理”过程，从而更准确地诊断Jitter等问题。
Q5：在实际工作中，如果我发现“非受限数据量百分比”很高，应该采取哪些优化措施？ A5：如果发现小包业务占比很高，优化的重心应该从提升峰值带宽转向降低调度时延和提高调度公平性。具体措施可能包括：1）调整QoS调度策略，为小包业务（通常有特定的5QI）分配更高的权重或专用的资源片；2）优化调度器算法，避免为了打包成更大的传输块而过度延迟小包的发送（即减少所谓的“packet aggregation delay”）；3) 检查和优化随机接入（RACH）信道配置，确保需要发送上行小包的用户能快速接入；4）在可能的情况下，开启如“上行免授权传输（Grant-free UL）”等特性，让小包可以无需等待调度指令直接发送。