好的，我们继续进行系列的下一篇深度解读。

深度解析 3GPP TS 28.552：附录A.1-A.4 RAN用户面质量监控实战

本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中，附录A (informative) “Use cases for performance measurements” 的 A.1至A.4章节，旨在为读者展示如何将前面学到的零散性能测量项，组合成解决实际问题的“战术 playbook”。

引言：无人机“DroneExpress-007”的空中险情

“王哥，看这份紧急报告！”小林将一份来自“DroneExpress”物流公司的性能报告投到大屏上，“他们新开通的5G无人机配送航线，最近频繁出现问题。报告显示，无人机‘DroneExpress-007’在飞越滨江开发区时，偶尔会发生短暂的‘指令延迟’，导致飞行姿态调整不畅；同时，回传的4K高清巡检视频，也会出现‘画面冻结’。他们要求我们必须解决这个问题，否则将影响整个航线的安全认证。”

老王看着屏幕上无人机飞行的轨迹，神情严肃：“小林，这不再是普通的手机上网体验问题了。无人机配送，是典型的uRLLC（超可靠低时延通信）和eMBB（增强移动宽带）混合应用场景。‘指令延迟’威胁的是飞行安全，‘画面冻egi结’则影响了地面巡检的有效性。我们之前学习了TS 28.552这部‘天书’的每一个‘字’（测量项），现在，是时候学习如何将这些‘字’组成‘句子’，写出一份精准的‘诊断报告’了。”

他将规范翻到了附录A。“Annex A: Use cases for performance measurements”，这一部分不再是枯燥的定义，而是3GPP官方编写的“实战案例集”。它告诉我们，在面对具体性能问题时，应该如何组合使用我们在正文中学习的各种测量工具。

“今天，我们就以‘DroneExpress-007’的空中险情为案例，重点学习附录A.1到A.4，看看如何对NG-RAN的用户面（User Plane）质量，进行一次端到端的、立体化的健康诊断。我们将学习区分‘延迟’与‘时延’，定位‘丢包’与‘丢弃’，最终找出导致无人机‘迷航’的真正元凶。”

1. “快”与“慢”的辩证法：时延(Latency) vs 延迟(Delay) (A.1 & A.4)

“要诊断‘指令延迟’和‘画面冻结’，我们首先要学会区分两个极易混淆的概念：Latency和Delay。”老王强调道。

A.1 Monitoring of UL and DL user plane latency in NG-RAN The DL IP latency monitoring in NG-RAN refers to the transmission within gNB of IP packets arriving when there is no other prior data to be transmitted to the same UE in the gNB.

A.4 Monitoring of UL and DL user plane delay in NG-RAN The DL delay monitoring in gNB refers to the delay of any packet within NG-RAN, including air interface delay until the UE receives the packet.

1.1 深度解析：首包与任意包

• IP Latency (IP时延 - A.1): 规范明确指出，它衡量的是当网络中没有其他数据需要发送给该UE时，一个新到达的IP包（首包）的传输时间。它反映的是网络的初始响应速度。这个指标对于“DroneExpress-007”的控制指令至关重要。一次紧急的“悬停”指令，必须以最快的速度送达，任何“首包时延”的增加，都可能导致无人机错过最佳的避障时机。这个时延主要由5.1.3.4 IP Latency measurements中的DRB.RlcSduLatencyDl等指标来衡量。

• Packet Delay (包延迟 - A.4): 规范定义它为任意数据包 (any packet) 在网络中的传输时间。它反映的是数据流的持续传输性能和抖动 (Jitter) 情况。对于“DroneExpress-007”回传的4K视频流，它是由成千上万个连续的数据包组成的。单个包的延迟不重要，但整体的平均延迟和延迟的稳定性（即抖动），直接决定了画面是否流畅。这个延迟主要由5.1.1.1.1 Average delay DL air-interface等指标来衡量。

1.2 场景化诊断：用分布图看清问题本质

小林调取了“DroneExpress-007”在问题区域的IP时延分布和包延迟分布数据。

• IP时延分布 (DRB.RlcSduLatencyDlDist.Bin): 发现有少数样本落在了>50ms的高时延区间。
• 包延迟分布 (DRB.AirIfDelayDist.Bin): 同样发现有少量样本落在了高延迟区间，导致了整体延迟分布的“长尾效应”。

“王哥，”小林分析道，“数据显示，网络并非持续性的慢，而是存在偶发性的高时延和高延迟。这既影响了指令的‘首包’响应，也造成了视频流的‘任意包’卡顿。但原因是什么呢？”

2. “消失的数据包”：丢包(Loss) vs 丢弃(Drop) (A.2 & A.3)

“时延和延迟的抖动，很多时候是网络内部‘拥堵’或‘重传’的表象。要找到根源，我们得看看，是不是有数据包在路上‘消失’了。”老王引导小林转向下一组关键用例。

A.2 Monitoring of UL and DL packet loss in NG-RAN UL packet loss is a measure of packets dropped in the UE and the packets lost on the interfaces (air interface and F1-U interface). DL packet loss is a measure of packets lost on the interfaces…

A.3 Monitoring of DL packet drop in NG-RAN Keeping track of DL packet drops in the NG-RAN is essential… For gNBs that are deployed in a split architecture… the DL packet drops may occur in two parts; the gNB CU-UP and the gNB DU.

2.1 深度解析：外部事故 vs 内部决策

• Packet Loss (丢包 - A.2): 这是一个更端到端的概念，通常指数据包因为不可控的外部原因而丢失。在DL方向，它主要衡量的是数据包在空口（Uu接口）因为信号差、干扰强，即使经过多次重传后依然无法被UE成功接收的事件。它由5.1.1.35 DL Packet Loss rate on Uu (DRB.PacketLossRateUu) 来衡量。高Packet Loss率，明确指向了无线环境的恶劣。

• Packet Drop (丢弃 - A.3): 这是一个网元内部的概念，指数据包因为设备内部拥塞而被主动丢弃。附录A.3特别强调，在分离式gNB架构下，丢弃可能发生在两个地方：

  1. gNB-CU-UP: 由5.1.3.2.1 DL PDCP SDU Drop rate in gNB-CU-UP (DRB.PdcpPacketDropRateDl) 衡量。
  2. gNB-DU: 由5.1.3.2.2 DL RLC SDU Packet Drop Rate in gNB-DU (DRB.RlcPacketDropRateDl) 衡量。 高Packet Drop率，明确指向了网络内部的处理或转发瓶颈。

2.2 场景化故障定界：“最后一跳”的瓶颈现形

小林按照老王的指导，开始了“排除法”诊断：

1. 检查空口丢包 (DRB.PacketLossRateUu): 他发现，在无人机发生问题的区域，这个值近乎为0。

   • 初步结论: 无线空口链路本身是可靠的！问题不出在“最后一公里”的交付上。这排除了信号覆盖不足或持续性强干扰的可能性。

2. 检查CU-UP丢弃 (DRB.PdcpPacketDropRateDl): 这个值也为0。

   • 进一步结论: 问题不出在“大脑”（CU）。CU的处理能力和通往DU的F1接口都是正常的。

3. 检查DU丢弃 (DRB.RlcPacketDropRateDl): 在无人机报告“指令延迟”和“画面冻结”的时刻，这个指标出现了明显的、尖锐的脉冲式增长！

“王哥，抓到元凶了！”小林激动地在拓扑图上DU的位置画了一个红圈，“数据包在CU和F1接口上一路畅通，但在DU的缓冲区里，被大量主动丢弃了！这意味着，数据到达DU后，因为某种原因，无法被及时地发送到空口，导致了缓冲区溢出。”

最终诊断： 结合之前的时延/延迟分布分析，整个故障链条被完整地还原了：

• 根本原因: 无人机在飞越滨江开发区时，受到了某个未知的、瞬时性的强脉冲干扰（可能是某个雷达或工业设备）。
• 直接影响: 这种瞬时干扰，导致空口的物理信道在短时间内（可能就几十毫秒）完全不可用，gNB的调度器无法分配任何PDSCH资源。
• 连锁反应: 此时，来自F1接口的数据仍在源源不断地到达DU，但无法被发送出去，迅速填满了DU的RLC/MAC缓冲区。
• 最终现象:
  1. 为了防止缓冲区彻底崩溃，DU的拥塞控制算法开始主动丢弃数据包（DRB.RlcPacketDropRateDl飙升）。这些被丢弃的包，对于上层应用来说，就表现为视频画面的“冻结”。
  2. 与此同时，新到达的、高优先级的“悬停”指令包，也被堵在了拥塞的缓冲区队列中，经历了很长的排队时间才被发送出去，这就表现为“指令延迟”（高IP Latency）。

3. 从诊断到优化

“诊断清晰了，优化方案也就水到渠成了。”老王总结道。

“不是去调整功率，也不是去改切换参数。我们应该立刻派出现场测试团队，携带频谱仪，去那个区域排查这个‘瞬时强干扰’的来源。在找到并消除干扰源之前，我们可以先通过软件优化，例如，为无人机专网启用更鲁棒的编码方案，或者在DU侧为uRLLC指令流配置一个‘免排队’的超高优先级队列，以牺牲一部分视频流为代价，确保控制指令的绝对低时延。”

结论：用例驱动，化零为整

通过对附录A.1-A.4的学习，我们体验了一次从理论到实践的完美闭环。这些用例，就像是经验丰富的“老法医”，教会了我们如何将零散的“尸检报告”（性能测量项），组合成一份逻辑严密、直指真凶的“破案卷宗”。

1. 区分核心概念 (Latency vs. Delay, Loss vs. Drop): 附录用例首先强调了对核心概念的精确理解，这是进行正确诊断的前提。
2. 提供诊断流程 (层层递进): 它展示了一个典型的故障排查思路：从端到端现象（时延/延迟分布）入手，然后通过分段测量（Uu Loss vs. F1 Loss vs. CU/DU Drop）进行故障域的层层剥离和定界。
3. 连接测量与根因: 它将抽象的测量指标，与具体的物理世界问题（如覆盖、干扰、拥塞）建立了清晰的因果关系，使得数据能够真正地指导优化行动。

附录A，是TS 28.552这部“字典”的“例句”部分。掌握了它，我们才真正学会了如何使用这门“5G性能语言”去描述问题、分析问题、解决问题。它标志着我们从一个“识字”的初学者，成长为一个能够“遣词造句”的实践者。

---

FAQ 环节

Q1：为什么规范要同时定义Packet Loss和Packet Drop？对于上层应用来说，它们不都是“收不到包”吗？ A1：是的，对于上层应用来说，结果都是一样的。但对于网络运维工程师来说，它们的意义天差地别，因为它们指向了完全不同的故障根源和优化方向。Packet Loss（特指Uu接口的）高，说明无线环境有问题，你需要去排查覆盖、干扰、天线故障等RF问题。而Packet Drop高，说明网络内部发生了拥塞，你需要去排查CU/DU处理能力、F1/N3接口带宽、拥塞控制算法等设备和传输问题。混淆这两者，就像是把“路面有坑”和“路上堵车”当成一回事，会导致“南辕北辙”的优化。

Q2：我的网络IP Latency（首包时延）很低，但Packet Delay（包延迟）的平均值很高，这是什么情况？ A2：这是一个典型的网络拥塞或调度不公的信号。IP Latency低，说明网络在空闲时，对新业务的初始响应是很快的。但一旦进入持续传输阶段，Packet Delay很高，说明数据包在网络内部（很可能是在gNB的缓冲区）经历了长时间的排队等待。这可能是因为：1）下行链路拥塞，总的业务需求超出了小区的处理能力。2）QoS调度问题，你的业务流被赋予了较低的优先级，总是在为其他高优先级业务“让路”。3）Bufferbloat（缓冲区膨胀），设备缓冲区设置过大，导致即使在轻度拥塞下，数据包也会经历不必要的长时排队。

Q3：附录A中的这些用例，是强制要求网络设备支持的吗？ A3：附录A是Informative（资料性）的，而非Normative（规范性）的。这意味着它本身并不提出新的强制性要求，而是对正文中规范性章节内容的一种解释、示例和推荐用法。它更像是一份“官方最佳实践指南”。虽然设备商不被强制要求按照用例来实现功能，但这些用例清晰地阐述了3GPP制定这些测量项的“意图”，为所有厂商和运营商提供了一个共同的、关于如何使用这些数据来解决实际问题的“思想框架”。

Q.4：在Cloud-RAN架构下，诊断用户面质量问题，最应该先看哪几个指标？ A.4：建议遵循“由外向内，分层诊断”的原则，建立一个“仪表盘”：

1. 第一层（空口质量）： DRB.PacketLossRateUu。如果这个值高，问题大概率在无线侧。
2. 第二层（DU拥塞）： DRB.RlcPacketDropRateDl。如果第一层正常但此值高，问题在DU或其与空口的衔接处。
3. 第三层（中传质量）： DRB.F1UpacketLossRateDl 和 DRB.PdcpF1DelayDl。如果前两层正常但此层异常，问题在中传网络。
4. 第四层（CU拥塞）： DRB.PdcpPacketDropRateDl。如果前三层正常但此值高，问题在CU-UP。 通过这样一套分层的仪表盘，可以非常高效地对Cloud-RAN的用户面问题进行定界。

Q5：这些测量能否用于上行业务的诊断？ A5：是的。附录A.1, A.2, A.4都明确提到了UL（上行）的监控。与下行类似，5G也提供了一套完整的上行用户面质量测量体系：

• 上行时延/延迟: gNB可以测量数据包从空口成功接收到离开N3接口的时间。
• 上行丢包/丢弃: UL PDCP SDU Loss Rate (5.1.3.1.1) 可以衡量从UE到CU-UP的端到端上行丢包率。UL F1-U Packet Loss Rate (5.1.3.1.2) 可以衡量F1-U接口的上行丢包。 通过这套上行测量，可以诊断如视频上传卡顿、云游戏指令延迟等上行业务问题。