深度解析 3GPP TS 28.522：5.1.1.34 & 5.1.1.35 & 5.1.1.36 & 5.1.1.37 GTPDL Packet Loss & Data Volume (N3NgU...

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

深度解析 3GPP TS 28.522：5.1.1.34 & 5.1.1.35 & 5.1.1.36 & 5.1.1.37 GTP/DL Packet Loss & Data Volume (N3/NgU接口的健康检查)

本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中，关于“5.1.1.34 Incoming GTP Data Packet Loss in gNB over N3”、“5.1.1.35 DL Packet Loss rate on Uu”、“5.1.1.36 Number of octets of incoming GTP data packets on the NgU interface”及“5.1.1.37 Number of octets of outgoing GTP data packets on the NgU interface”的核心章节，旨在为读者提供一个关于5G RAN与核心网之间关键接口（N3/NgU）传输质量与流量监控的性能测量解析。

引言：云游戏玩家“幻影”的“跨服卡顿”之谜

“王哥，我们又遇到了一个棘手的投诉！”小林将一份性能报告放在老王桌上，“云游戏顶级玩家‘幻影’，他使用的是我们为电竞酒店部署的5G专网切片。他反馈，最近每到晚上8点的黄金时段，游戏画面就会出现间歇性的、长达半秒的‘冻结’。奇怪的是，我们检查了所有无线侧的指标——RSRP、SINR、CQI、BLER——全都非常完美。他的平均时延也很低。问题到底出在哪？”

老王沉思了片刻，在网络架构图上，用红笔圈出了连接gNB（基站）和UPF（用户面功能）的那条线。“小林，我们之前的所有排查，都聚焦在UE和gNB之间的‘最后一公里’，也就是Uu接口（空口）。但别忘了，数据不是在基站凭空产生的。对于云游戏来说，游戏画面数据需要从远端云服务器，经过核心网的UPF，再通过这条N3接口，才能到达gNB。如果这条‘高速公路’本身出了问题，就算‘最后一公里’的路况再好，车也过不来。”

他将TS 28.552翻到了5.1.1.34及后续的相关章节。“今天，我们要把视线从无线空口，延伸到RAN与核心网的‘握手’之处——N3接口，以及它在gNB侧的等效端点NgU接口。这一系列的测量项，就是我们对这条‘信息大动脉’进行的‘健康检查’。我们要检查两个核心问题：第一，这条路上的‘包裹’（GTP包）有没有在运输途中丢失？第二，这条路上的‘车流量’（数据量）到底有多大？”

这篇文章，我们将化身为“网络交通警察”，通过分析N3/NgU接口的丢包与流量测量，来侦破云游戏玩家“幻影”遇到的“跨服卡顿”之谜，揭示保障端到端业务质量中，承载网监控的重要性。

1. “包裹”去哪了？：GTP与Uu接口的丢包测量

数据在N3接口上传输时，会被封装在GTP-U（GPRS隧道协议-用户面）的包里。GTP包通过序列号（Sequence Number）来保证传输的有序性。如果gNB发现收到的GTP包序列号不连续，就意味着中间有包在传输途中丢失了。

1.1 大动脉的“运输损耗”：Incoming GTP Data Packet Loss in gNB over N3 (5.1.1.34)

a) This measurement provides the number of GTP data packets which are not successfully received at gNB over N3 after being sent by UPF. It is a measure of the incoming GTP data packet loss per N3 interface. The measurement is split into subcounters per QoS level (5QI) and subcounters per supported S-NSSAI.

c) This measurement is obtained by a counter: Number of missing incoming GTP sequence numbers (TS 29.281) among all GTP packets delivered by a UPF to a gNB per N3 interface.

e) GTP.InDataPktPacketLossN3gNB or GTP.InDataPktPacketLossN3gNB.QoS… or GTP.InDataPktPacketLossN3gNB.SNSSAI…

1.1.1 深度解析

GTP.InDataPktPacketLossN3gNB (GTP Input Data Packet Loss on N3 at gNB) 是诊断N3接口传输质量的“探针”。

• 测量对象: 从UPF发往gNB，但在N3接口传输过程中丢失的GTP数据包数量。
• 测量方法: gNB通过检查收到的GTP包的序列号来发现“缺口”。例如，gNB收到了序列号为100和102的包，却没有收到101，那么它就判定序列号为101的包已经丢失，并将相应的计数器加1。
• 关键过滤维度: 5QI和S-NSSAI。这使得我们可以精确地统计，是哪个切片、哪种业务类型的GTP包在N3接口上发生了丢包。
• 物理意义: 这个指标直接反映了**承载N3接口的传输网络（Transport Network）**的健康状况。这个传输网络可能是运营商自建的光纤环网，也可能是租用的第三方专线。它的丢包，通常与传输设备拥塞、光缆抖动、路由震荡等因素有关。

1.2 “最后一公里”的损耗：DL Packet Loss rate on Uu (5.1.1.35)

a) This measurement provides the DL Packet (i.e., RLC SDU) Loss rate on Uu interface for an NR cell.

c) This measurement is obtained based on the following parameters defined in TS 38.314: Dloss(T, drbid) [丢失的RLC SDU数] and N(T, drbid) [成功传输的RLC SDU数].

The gNB takes the following calculation…: ∑(Dloss) * 1000000 / ∑(N + Dloss)

1.2.1 深度解析

DRB.PacketLossRateUu 则将视线拉回到了我们熟悉的无线空口（Uu接口）。它衡量的是，一个RLC SDU在gNB侧已经准备好发送给UE，但最终因为种种无线原因（如达到最大重传次数后依然失败）而被gNB判定为丢失的比率。

• 测量对象: 在RLC层面，被判定为在Uu接口上最终丢失的数据包（RLC SDU）。
• 测量方法: 计算公式为 (丢失的包数) / (总包数)，其中总包数 = 成功传输的包数 + 丢失的包数。结果乘以1,000,000，表示为百万分之几的比率。
• 物理意义: 这个指标直接反映了无线空口环境的恶劣程度和HARQ/RLC重传机制的极限。高Uu丢包率通常与严重的干扰、深度衰落或移动速度过快等无线问题相关。

1.3 场景化诊断：“跨服卡顿”的根源定位

小林立刻调取了“幻影”所在电竞切片的N3和Uu丢包数据。

• Uu接口 (DRB.PacketLossRateUu.SNSSAI_Gaming): 丢包率为 0。

  • 分析: 这证实了之前的判断，无线环境非常好，空口的“最后一公里”配送堪称完美。

• N3接口 (GTP.InDataPktPacketLossN3gNB.SNSSAI_Gaming): 计数值在晚上8点的高峰时段，出现了规律性的、每隔几分钟就跳升几十个的现象！

“王哥，找到了！”小林激动地指着N3丢包计数器的曲线，“‘幻影’的游戏画面冻结，和N3接口的瞬时丢包，在时间上是完美对应的！数据包在到达基站之前，就已经在‘高速公路’上丢失了！”

洞察与行动： 通过区分N3接口丢包和Uu接口丢包，运维团队成功地将故障域从复杂的无线环境，精准地锁定到了承载网。后续的深入排查发现，承载该区域gNB到UPF流量的一台汇聚交换机，在晚高峰时段因为其他高流量业务的冲击，其QoS队列发生了拥塞和溢出，导致了对时延敏感的云游戏GTP包的随机丢弃。 解决方案也变得非常清晰：调整交换机的QoS策略，为电竞切片的GTP流（可以通过DSCP等标记识别）分配更高的队列优先级和保护策略。

2. “大动脉”的流量监控：NgU接口数据量测量 (5.1.1.36 & 5.1.1.37)

NgU接口是gNB的用户面逻辑端点，可以看作是N3接口在RAN侧的“终点站”。监控这个接口的流量，对于容量规划和网络切片资源管理至关重要。

5.1.1.36 Number of octets of incoming GTP data packets on the NgU interface, from UPF to RAN a) This measurement provides the number of octets of incoming GTP data packets on the NgU interface at gNB/CU-UP end… The measurement can optionally be split into sub-counters per S-NSSAI. e) GTP.InDataOctNgUgNB and optionally GTP.InDataOctNgUgNB.SNSSAI…

5.1.1.37 Number of octets of outgoing GTP data packets on the NgU interface, from RAN to UPF (定义与下行对称，方向为上行)

2.1 深度解析

GTP.InDataOctNgUgNB (Incoming Octets on NgU at gNB) 和 GTP.OutDataOctNgUgNB (Outgoing Octets) 是衡量N3/NgU接口实际承载流量的基础指标。

• 测量对象: 在NgU接口上，gNB接收（下行）或发送（上行）的GTP-U数据包的总字节数（Octets）。这个统计包含了GTP头和内部的用户IP包，反映了在承载网上传输的真实数据量。
• 测量方法: 简单的累计计数。通过在统计周期开始和结束时读取两次计数器的值，相减后除以时长，就可以计算出该接口的平均吞吐率。
• 关键过滤维度: S-NSSAI。这是实现网络切片流量监控和计费的根本。

2.2 场景化应用：网络切片的“水表”

在智慧港口的案例中，运营商为港务局提供了多个切片，如“AGV控制切片”、“视频监控切片”和“办公普通上网切片”。

1. 容量监控与规划: 通过持续监控每个切片的GTP.InDataOctNgUgNB.SNSSAI_xxx和GTP.OutDataOctNgUgNB.SNSSAI_xxx，运维团队可以清晰地看到每个切片在一天中不同时段的流量潮汐。当某个切片的流量持续接近其在N3接口上分配的带宽上限时，系统就可以自动告警，提示需要进行扩容。

2. SLA保障与计费: 这组数据是切片SLA保障的“铁证”。如果AGV控制切片的SLA承诺了100Mbps的上行带宽，那么GTP.OutDataOctNgUgNB.SNSSAI_AGV在业务高峰期的平均速率，就必须达到或超过这个值。同时，这些按切片统计的精确流量，也是运营商与行业客户进行结算的依据。

3. 故障排查关联: 当“幻影”反馈卡顿时，小林在分析丢包的同时，也查看了GTP.InDataOctNgUgNB.SNSSAI_Gaming的流量。他发现，每次丢包事件发生前，该接口的总流量（所有切片之和）都会达到一个峰值。这个关联分析，进一步佐证了问题是由于传输设备拥塞导致的。

结论：N3接口测量——端到端质量保障的“中流砥柱”

通过对“跨服卡顿”之谜的侦破，我们深刻体会到，将监控视野从空口延伸到N3接口的重要性。

1. 丢包测量 (PacketLoss) 是故障域划分的“裁决者”。通过对比Uu丢包和N3丢包，我们可以快速判断问题出在“无线侧”还是“承载侧”，避免了优化工作的南辕北辙。
2. 流量测量 (DataOct) 是容量管理和切片运维的“度量衡”。按S-NSSAI细分的上下行流量统计，是实现网络切片SLA监控、容量规划和商业计费不可或缺的基础。

空口（Uu接口）决定了用户体验的上限，而N3接口和其承载网的质量，则决定了这个上限能否被稳定地兑现。在5G时代，越来越多的业务（如云游戏、AR/VR、远程控制）对端到端的网络质量提出了前所未有的要求。N3接口的测量体系，正是保障这条“信息大动脉”畅通无阻的“中流砥柱”。

---

FAQ 环节

Q1：GTP-U的序列号是强制要求的吗？如果UPF没有加序列号，gNB还能检测丢包吗？ A1：根据3GPP TS 29.281的规定，为了支持基于丢包的QoS监控等功能，GTP-U头中需要包含序列号。如果UPF或gNB的某一方不支持或未开启序列号功能，那么基于序列号的丢包检测机制就无法工作，GTP.InDataPktPacketLossN3gNB这个测量项也就无法统计。在实际部署中，为了实现精细化的运维，运营商通常会要求设备商默认开启GTP-U的序列号功能。

Q2：DL Packet Loss rate on Uu (5.1.1.35) 和我们之前学的 Residual error number of DL TBs (5.1.1.7.5) 有什么关系？ A2：它们之间有很强的因果关系。Residual error number of DL TBs是物理层（PHY）的测量，统计的是一个TB经过了所有HARQ重传后，最终仍然失败的次数。这种失败是导致DL Packet Loss rate on Uu的主要原因之一。当一个TB最终解码失败后，其承载的上层数据（RLC SDU）就会被RLC层判定为丢失（如果RLC也达到最大重传次数），从而被Dloss计数器统计。可以说，rBLER是因，Uu丢包是果。

Q3：NgU接口和N3接口是什么关系？为什么测量项的名字里有时用N3，有时用NgU？ A3：N3接口是3GPP系统架构图中定义的、连接NG-RAN（gNB）和UPF之间的参考点（Reference Point）。而NgU接口可以理解为N3接口在gNB侧的具体实现和协议端点，它承载着GTP-U协议。在规范的命名中，N3通常用于描述这个接口的逻辑位置和场景（例如，...LossN3gNB强调了是在N3接口上、在gNB侧检测到的丢包）。而NgU则更多地从协议和实体的角度来描述（例如，...OctNgUgNB强调了是在NgU这个协议端点上统计的字节数）。在实际理解中，可以将它们视为同一接口的不同称谓。

Q4：测量到的N3接口丢包，一定是承载网的问题吗？ A4：绝大多数情况下是的，但也存在其他可能。N3丢包的本质是“UPF已发，但gNB未收”。最常见的原因是中间的承载网（路由器、交换机）因为拥塞、故障或路由问题导致丢包。但理论上也存在极端情况，例如：1）UPF本身因为负载过高或软件缺陷，虽然生成了序列号，但在发送时就发生了丢包。2）gNB侧的硬件（如网卡）或底层驱动有问题，导致收到的包在被GTP协议栈处理前就被丢弃了。因此，在定位到N3丢包后，还需要传输和核心网的同事进一步协同排查。

Q5：Number of octets（字节数）和Number of packets（包数）这两个流量指标，在优化中各自的侧重点是什么？ A5：两者提供了互补的信息。Number of packets（包数）更能反映网络的信令处理和转发压力。无论一个包是100字节还是1500字节，网络设备都需要为其进行一次路由查找、QoS处理等操作。高pps（packets per second）会对设备的CPU和处理能力带来巨大压力。而**Number of octets（字节数）更能反映网络的带宽占用和容量压力**。它直接关系到物理链路的负载。在云游戏场景中，我们既要关注字节数（带宽是否足够），也要关注包数（UPF和gNB的转发能力是否成为瓶颈）。