深度解析 3GPP TS 28.552：5.1.1.1 Packet Delay (Part 1 - 5G空口时延的精细解剖)

本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中，关于“5.1.1.1 Packet Delay”的核心章节，旨在为读者提供一个5G网络端到端时延测量的精细视图，并重点剖析空口各环节的时延构成与测量方法。

引言：电竞大神“Leo”的烦恼

“王哥，快看这个投诉！” 刚入职的网优工程师小林拿着平板电脑，快步走到导师老王身边。屏幕上是一封措辞激烈的用户投诉邮件。

投诉人ID是“ProGamer_Leo”，一位小有名气的职业电竞选手。他在邮件中写道：“你们新部署的5G网络到底行不行？我在我们战队新启用的5G训练基地，网络速率测试飞快，但每隔几分钟，游戏操作就会有一次明显的卡顿，延迟瞬间从5ms飙到80ms以上！对于职业选手来说，这零点几秒的延迟就是生与死的区别！如果解决不了，我们只能换回有线网络了！”

老王看完邮件，微微一笑：“有挑战性，是件好事。这正是我们展示5G网络确定性能力的机会。Leo遇到的问题，是典型的‘平均速率’无法体现的‘瞬时体验’问题。要解决它，我们就必须深入到网络的心跳——数据包的时延。走，打开我们的‘手术刀’TS 28.552，我带你给Leo的网络体验做一次精密的‘时延解剖手术’。”

老王打开了规范的第5.1.1.1节——“Packet Delay (包时延)”。“这一节，就是我们诊断所有‘卡顿’、‘延迟’问题的圣经。它把一个数据包从核心网边界到手机APP的整个旅程，切分成了无数个可以精确测量的‘赛段’。今天，我们就从用户感受最直接的无线空中接口开始，看看如何用规范定义的‘探针’，找到导致Leo操作卡顿的‘元凶’。”

这篇文章，我们将化身网络侦探，跟随老王和小林的脚步，逐一拆解3GPP TS 28.552中关于包时延的各项测量定义。我们将看到，3GPP是如何用一系列精妙绝伦的测量方法，将无形的网络时延，变得可度量、可分析、可优化。

1. 空口下行时延的“平均脸”：5.1.1.1.1 Average delay DL air-interface

老王打开了第一个测量项，对小林说：“这是我们最先要看的数据，下行空口平均时延。它就像一个人的‘平均脸’，能给我们一个大概的印象。”

a) This measurement provides the average (arithmetic mean) time it takes for packet transmission over the air-interface in the downlink direction. The measurement is optionally calculated per PLMN ID and per QoS level (mapped 5QI or QCI in NR option 3) and per supported S-NSSAI. c) This measurement is obtained as: sum of (point in time when the last part of an RLC SDU packet was sent to the UE which was consequently confirmed by reception of HARQ ACK from UE for UM mode or point in time when the last part of an RLC SDU packet was sent to the UE which was consequently confirmed by reception of RLC ACK for AM mode, minus time when corresponding RLC SDU part arriving at MAC layer) divided by total number of RLC SDUs transmitted to UE successfully. e) DRB.AirIfDelayDl or DRB.AirIfDelayDl_Filter, where Filter is a combination of PLMN and QOS and SNSSAI…

1.1 深度解析

老王开始逐条为小林解读：

“首先，看a)项，理解测量的‘目标’是什么。”

这句话的核心是“average time”、“over the air-interface”、“downlink direction”。也就是说，这个测量项统计的是，一个数据包（准确地说是RLC SDU）在基站侧，从准备好被发送，到最终在手机上被成功接收，这段‘空中之旅’所花费的平均时间。

“其次，看c)项，理解测量的‘方法’。”

这是整个测量项的灵魂，定义了时延计算的起点和终点，必须精确理解。老王画了一张简单的流程图：

1. 起点 (T_start): time when corresponding RLC SDU part arriving at MAC layer。一个IP包从核心网传下来，经过gNB的PDCP层和RLC层，被切分成RLC SDU。当这个RLC SDU的数据块被提交给MAC层，准备打包成TB（传输块）发送时，时钟开始计时。这标志着它在基站内部的处理基本完成，进入了等待空中调度的队列。

2. 终点 (T_end): point in time when the last part of an RLC SDU packet was sent to the UE which was consequently confirmed...。MAC层将RLC SDU打包后通过物理层发送出去，手机接收后会回复一个确认信息（HARQ ACK或RLC ACK）。当基站收到这个确认信息，证明手机已经‘签收’，时钟停止。

3. 计算: 单个包的空口时延 = T_end - T_start。然后，在一个统计周期内，将所有成功发送的包的时延累加起来，再除以总包数，就得到了我们看到的Average delay DL air-interface。

小林恍然大悟：“原来这么复杂！这个确认机制很关键，它确保了我们测量的是真正‘成功送达’的时延。”

“没错，”老王点头，“否则，如果一个包在空中丢了，我们却不知道，那测出来的时延就没有意义了。”

1.2 场景化举例：Leo的游戏数据包之旅（下行）

为了让小林理解得更透彻，老王把Leo的场景带了进来。

“想象一下，Leo在游戏中开了一枪。这个‘开枪’的指令从游戏服务器发出，通过核心网到达基站。我们假设这个指令数据被封装在一个IP包里。”

1. 进入等待队列 (T_start): IP包在gNB内部被处理成一个RLC SDU，在t0时刻被送到了MAC层。MAC层一看，这是一个高优先级的游戏数据包（通过5QI识别），需要立刻调度。
2. 空中飞行与确认 (T_end): MAC层在t0 + 2ms时找到了合适的无线资源，通过物理层将它发送给了Leo的手机。Leo的手机在t0 + 3ms时成功接收，并立刻回复了一个HARQ ACK。基站在t0 + 5ms时收到了这个ACK。
3. 单包时延: 那么，这个游戏数据包的下行空口时延就是5ms - 0ms = 5ms。

“在一个统计周期（比如15分钟）内，基站会计算成千上万个这样数据包的时延，最后给出一个平均值。同时，通过Filter，我们可以让基站只统计Leo所使用的那个电竞切片（SNSSAI）或者游戏业务（QOS）的数据包时延，从而排除其他业务的干扰。”

小林调出了Leo所在小区的DRB.AirIfDelayDl数据，发现平均值稳定在6ms左右。“王哥，这个平均值很优秀啊，不像是会卡顿的样子。”

2. 揭开“平均脸”下的真相：5.1.1.1.2 Distribution of delay DL air-interface

“这正是‘平均脸’的迷惑性所在，”老王指着屏幕说，“一个班平均分85，可能是所有人都考85，也可能是一半人考100，一半人考70。对于Leo来说，99次5ms的流畅体验，也抵消不了1次80ms卡顿带来的挫败感。所以，我们必须看下一个测量项——时延分布。”

a) This measurement provides the distribution of the time it takes for packet transmission over the air-interface in the downlink direction… c) This measurement is obtained by 1) calculating the DL delay for an RLC SDU packet by: [方法同5.1.1.1.1]…; and 2) incrementing the corresponding bin with the delay range where the result of 1) falls into by 1 for the counters.

2.1 深度解析

“这个测量项的计算方法和上一个完全一样，唯一的区别在于最后的数据处理方式。”老王解释道，“它不再是求平均值，而是做一个‘直方图’（histogram）。”

基站内部会预设一系列的时延区间，也就是“bin”，例如：

• Bin 1: 0-5 ms
• Bin 2: 5-10 ms
• Bin 3: 10-20 ms
• Bin 4: 20-40 ms
• Bin 5: > 40 ms

每当一个数据包的时延被计算出来，基站就会判断它属于哪个区间，然后给那个区间的计数器加1。

“比如，刚才Leo那个5ms的包，就会让‘Bin 1’的计数器加1。如果下一个包时延是8ms，就给‘Bin 2’加1。如果突然有个包因为无线干扰重传，时延变成了35ms，就给‘Bin 4’加1。”

2.2 场景化举例：找到卡顿的“幽灵”

小林立刻切换视图，调出了DRB.AirIfDelayDist.Bin_Filter（按游戏业务的5QI过滤）的时延分布图。

图表显示：

• Bin 1 (0-5ms): 1,500,000个包 (占比98.6%)
• Bin 2 (5-10ms): 20,000个包 (占比1.3%)
• Bin 3 (10-20ms): 1,000个包 (占比0.06%)
• Bin 4 (20-40ms): 50个包
• Bin 5 (>40ms): 25个包

“找到了！”小林激动地指着图表，“王哥快看，虽然绝大部分包的时延都很好，但确实有那么一小撮‘幽灵’数据包，它们的时延超过了40ms！虽然数量少，但足以毁掉Leo的游戏体验了。”

老王满意地点点头：“非常好。现在我们已经从‘感觉网络不错’，精准定位到了‘存在偶发性高时延数据包’。这就是时延分布测量的威力。它让我们看到了平均值之下隐藏的魔鬼。”

3. 上行之路的探索：UL Packet Delay (5.1.1.1.3 - 5.1.1.1.5)

“下行问题找到了，但我们不能放过任何一个疑点。电竞游戏，上行操作的延迟同样致命。”老王引导小林继续探索。

规范中定义了三个与上行时延相关的核心测量：

• 5.1.1.1.3 Average delay UL on over-the-air interface: 上行空口平均时延。
• 5.1.1.1.4 Average RLC packet delay in the UL: 上行RLC层平均时延。
• 5.1.1.1.5 Average PDCP re-ordering delay in the UL: 上行PDCP重排序平均时延。

c) This measurement is obtained according to the definition in TS 38.314, named “Average over-the-air interface packet delay in the UL per DRB per UE”. (for 5.1.1.1.3) c) This measurement is obtained according to the definition in TS 38.314, named “Average RLC packet delay in the UL per DRB per UE”. (for 5.1.1.1.4) c) This measurement is obtained according to the definition in TS 38.314, named “Average PDCP re-ordering delay in the UL per DRB per UE”. (for 5.1.1.1.5)

3.1 深度解析

“你会发现，这三个上行测量的定义都直接引用了另一本规范TS 38.314，这是L2测量的专门规范。”老王解释，“这再次体现了规范的模块化思想。我们简单理解一下它们的区别：”

• 上行空口时延 (AirIfDelayUl): 衡量的是数据包从手机MAC层发出，到基站MAC层成功接收的“空中”时间。这是最核心的上行时延指标。
• 上行RLC时延 (RlcDelayUl): 衡量的是数据包在gNB-DU内部，从RLC层接收到，到被送往PDCP层的时间。它主要反映了DU侧的处理性能。
• 上行PDCP重排序时延 (PdcpReordDelayUl): 在一些高级场景，比如双连接（DC），来自两个基站的数据包可能乱序到达gNB-CU。PDCP层需要缓存后来的包，等待先发的包，这个等待时间就是重排序时延。它反映了多流聚合场景下的处理开销。

3.2 场景化举例：Leo的反击指令

“Leo按下射击键，这个指令通过上行数据包发送。我们分析DRB.AirIfDelayUl的平均值和分布，发现都非常理想，稳定在2-3ms。RlcDelayUl和PdcpReordDelayUl更是接近于0。这说明，上行链路非常健康，问题基本可以锁定在下行了。”

4. 端到端视野：从核心网到UE的全链路时延测量 (5.1.1.1.6 - 5.1.1.1.8)

“现在我们已经确认问题出在下行空口，但作为一个优秀的工程师，我们要有全局视野。规范还提供了测量更长‘赛段’时延的工具，能帮助我们排除其他环节的嫌疑。”老王将视野拉远。

这部分测量引入了一种特殊的机制：GTP-U PDU监控。简单来说，核心网的UPF会发送一些特殊的“探针”数据包，gNB和UE会对这些包打上时间戳，从而计算出更大范围的时延。

4.1 NG-RAN到UE的全程时延 (5.1.1.1.6 & 5.1.1.1.7)

a) This measurement provides the distribution of DL/UL packet delay between NG-RAN and UE, which is the delay incurred in NG-RAN (including the delay at gNB-CU-UP, on F1-U and on gNB-DU) and the delay over Uu interface.

• 5.1.1.1.6 Distribution of DL delay between NG-RAN and UE
• 5.1.1.1.7 Distribution of UL delay between NG-RAN and UE

这两个测量项衡量的是一个数据包从进入gNB（N3接口）到被UE成功接收（下行），或者从UE发出到离开gNB（N3接口）（上行）的整个RAN侧处理+空口时延。

老王解释：“这就像测量一个人跑完整个体育场一圈的时间，而不仅仅是最后100米冲刺。通过分析DRB.DelayDlNgranUeDist.Bin的分布，我们发现高时延包的现象依然存在，这印证了我们的判断：问题就出在RAN内部，而不是更上游的核心网。”

4.2 承载网时延：NG-RAN与UPF之间 (5.1.1.1.8)

a) This measurement provides the average/distribution of DL GTP packet delay between PSA UPF and NG-RAN. This measurement is only applicable to the case the PSA UPF and NG-RAN are time synchronised.

这个测量项更进一步，直接测量了数据包在**N3接口（核心网UPF和gNB之间）**的传输时延。

“这测量的是连接UPF和gNB的承载网质量。”老王说，“我们看了下GTP.DelayDlPsaUpfNgranMean，平均时延只有1ms，非常稳定。这彻底排除了承载网抖动导致Leo游戏卡顿的可能性。所有证据都指向了我们最初的判断——下行空口的调度问题。”

结论：用“时延手术刀”精准定位问题

在老王的指导下，小林通过系统性地分析TS 28.552中定义的从微观到宏观的各项时延测量，一步步抽丝剥茧，成功地将一个模糊的“游戏卡顿”投诉，精准定位到了“下行空口调度引起的偶发性高时延”。

最终，他们发现该小区的下行调度器为了追求整体吞吐率最大化，其参数设置对于需要持续、稳定低时延的小包业务（如游戏）不够友好，在某些调度周期内会将游戏包的优先级排后。在调整了相关QoS调度权重参数后，Leo反馈游戏卡顿问题彻底消失。

老王总结道：“小林，记住，我们面对的不是一堆杂乱的数字，而是一套逻辑严密的测量体系。今天我们只用了‘Packet Delay’这一把手术刀，就已经解决了一个棘手的问题。整部28.552规范，就是我们工具箱里全套的‘精密仪器’。熟练掌握它，你才能成为一名真正的网络‘外科医生’。”

这只是我们深入5G性能测量世界的第一步。通过对“Packet Delay”的精细解剖，我们领略了3GPP规范的严谨与强大。下一篇文章，我们将继续探索gNB性能的另一大核心领域——无线资源利用率，看看如何评估和优化5G网络的容量与效率。

---

FAQ 环节

Q1：为什么下行时延的起点是“RLC SDU到达MAC层”，而不是更早的“IP包到达gNB”？ A1：这是一个非常好的问题，体现了测量的精确性和解耦思想。时延可以分解为“处理时延”和“传输/等待时延”。将起点设置在MAC层，主要是为了精确测量“传输/等待时延”，即数据在空中传输以及等待无线资源调度所花费的时间。从IP包到达gNB到RLC SDU到达MAC层，这段时间是gNB内部协议栈的处理时延，它受基带芯片性能影响较大。将这两部分分开测量，有助于更清晰地定位问题：时延大是基站处理不过来，还是空口太拥堵。

Q2：什么是UM模式和AM模式下的ACK，它们在时延测量中有什么不同？ A2：UM（Unacknowledged Mode，非确认模式）和AM（Acknowledged Mode，确认模式）是RLC层的两种数据传输模式。UM模式是“尽力而为”的传输，不保证数据一定送达，它通常依赖更底层的HARQ（混合自动重传请求）机制来做快速确认和重传。AM模式则有自己的序列号和状态报告机制，能保证数据可靠、有序地送达。在时延测量中，UM模式的终点以收到MAC层的HARQ ACK为准，这更快、更实时；而AM模式的终点以收到RLC层的ACK为准，这代表了数据在RLC协议层面的最终确认。

Q3：为什么测量“NG-RAN与UPF之间”的时延（5.1.1.1.8）要求时间同步？ A3：因为这是一个“单向时延”的测量。该测量是通过比较数据包离开UPF的时间戳（T1）和到达gNB的时间戳（T2）来计算的，即Delay = T2 - T1。如果UPF和gNB的时钟存在偏差，哪怕只有几毫秒，这个计算结果就会完全失真。因此，精确的单向时延测量必须依赖高精度的时间同步（例如通过PTP/SyncE等技术），确保两端设备处于同一个时间基准上。

Q4：在上行时延测量中，PDCP重排序时延（5.1.1.1.5）在什么场景下会比较显著？ A4：PDCP重排序时延主要在采用了多路径传输的场景下才会变得显著。最典型的就是5G的“双连接”（Dual Connectivity, DC），例如一个UE同时连接到一个宏基站和一个微基站。数据可以被分流从两条路径同时发往核心网。由于两条路径的传输时延不同，数据包到达汇聚点（gNB-CU的PDCP层）时就可能是乱序的。PDCP层必须启动一个定时器，缓存后到的包，等待先到的包，这个过程就会产生重排序时延。在单连接场景下，这个时延通常为零。

Q5：作为一名优化工程师，在日常工作中如何使用“平均时延”和“时延分布”这两个指标？ A5：这两个指标需要结合使用，形成“宏观监控”和“微观诊断”的闭环。首先，使用“平均时延”作为网络健康度的宏观监控指标，通过设置告警阈值（如，某区域平均时延连续1小时超过15ms则告警），可以快速发现大范围的性能劣化。一旦发现问题或收到用户投诉，就需要立即下钻分析“时延分布”，它能告诉你时延问题的严重程度（是整体劣化还是偶发抖动）和影响范围（影响了多少比例的数据包），从而为问题的定性和后续优化方向提供精确指引。简单来说，平均值告诉你“有没有病”，分布图告诉你“病得多重、是什么病”。