51学通信

深度解析 3GPP TS 28.552：5.4 UPF Measurements (5G数据平面的“超级立交桥”)

18分钟阅读

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

深度解析 3GPP TS 28.552：5.4 UPF Measurements (5G数据平面的“超级立交桥”)

本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中，关于“5.4 Performance measurements for UPF”的核心章节，旨在为读者提供一个关于5G网络用户面核心（UPF）的性能测量全景解析。

引言：全球电竞总决赛直播的“幕后英雄”

全球电竞总决赛的现场，数万名观众的5G手机正同时直播着高清画面。与此同时，全球数亿观众通过5G网络，以超低延迟、身临其境的第一视角，观看着这场巅峰对决。海量的上行直播流与下行观赛流，汇聚成一股前所未有的数据洪峰，对整个5G网络的用户面构成了极致的考验。

“王哥，这场决赛的并发流量太恐怖了！”网络优化中心，小林紧盯着流量监控大盘，感叹道，“数据从基站汇聚上来后，到底是在哪里进行分流、转发、计费，并最终送往互联网的？这个‘交通枢纽’的压力一定最大。”

老王指向核心网架构图的中心位置——UPF (User Plane Function, 用户面功能)。“小林，你找到了这场数据洪流的‘风暴眼’。UPF，就是5G数据平面的‘超级立交桥’和‘智能交通枢纽’。所有的用户数据，无论来自哪个基站、去往哪个互联网应用，都必须在这里汇聚，并由它根据SMF下发的‘交通规则’（N4规则），进行快速的路由转发、QoS保障、流量统计和合法监听。”

“这座‘立交桥’的吞吐能力、通行时延和可靠性，直接决定了数亿观众的最终体验。今天，我们就来学习TS 28.552的5.4节，看看如何为这座‘超级立交桥’进行一次全面的‘压力测试’和‘健康体检’。”

1. “立交桥”的交通规则：N4接口相关测量 (5.4.3 & 5.3.3)

UPF的所有行为，都受到来自SMF的指令控制。SMF与UPF之间的这个“指挥通道”，就是N4接口。N4会话的建立、修改、删除，决定了UPF能否为PDU会话正确地建立起数据通路。

(注：关于N4接口的测量，规范分别在SMF侧（5.3.3节）和UPF侧（5.4.3节）进行了定义，两者互为补充，我们在此合并解读，以UPF视角为主。)

5.4.3.1.1 Number of requested N4 session establishments (SM.N4SessionEstabReq) c) On receipt of N4 session establishment request message … by the UPF from SMF.

5.4.3.1.2 Number of failed N4 session establishments (SM.N4SessionEstabFail.cause) c) On transmission of N4 session establishment response message that contains the cause indicating the rejection…

5.3.3.1 Number of N4 session modifications (SM.N4SessionModify) (在SMF侧统计) 5.3.3.3 Number of N4 session deletions (SM.N4SessionDelete) (在SMF侧统计)

  • 深度解析: 这组测量SM.N4Session...监控了N4会话的完整生命周期。

    • 建立 (Establishment): 当SMF为PDU会话选择了某个UPF后，会向该UPF发送N4 Session Establishment Request，请求建立N4会话。Req在UPF收到请求时计数，Fail.cause在UPF因故（如资源不足）无法建立并返回失败响应时计数。N4会 Ush话建立成功率是衡量UPF可用性的关键。
    • 修改 (Modification): 当PDU会话的QoS、路由策略等发生变化时，SMF会发送N4 Session Modification Request来更新UPF上的处理规则。
    • 删除 (Deletion): 当PDU会话释放时，SMF会发送N4 Session Deletion Request来清除UPF上的会话资源。

  • 场景化应用: 如果SM.N4SessionEstabFail计数很高，说明UPF本身可能出现了过载或故障，无法再接收新的N4会话，这是UPF需要扩容或进行故障排查的强烈信号。

2. “立交桥”的车流量与拥堵状况：N3/N6/N9接口测量

UPF是多条“高速公路”的交汇点，规范为每一条核心“公路”都定义了详细的流量和质量测量。

  • N3接口: 连接gNB (RAN)。
  • N6接口: 连接DN (数据网络，如互联网)。
  • N9接口: 连接另一个UPF (用于多UPF级联的场景，如漫游)。

2.1 流量的度量：数据包与字节数 (5.4.1.1 - 5.4.1.6, 5.4.2, 5.4.4.2)

5.4.1.1 Number of incoming GTP data packets on the N3 interface (GTP.InDataPktN3UPF) 5.4.1.3 Number of octets of incoming GTP data packets on the N3 interface (GTP.InDataOctN3UPF) (以及N3出口、N6进出口、N9进出口的对应测量)

  • 深度解析: 这是一组最基础的流量统计测量。它们分别从“包数 (Pkt)”和“字节数 (Oct)”两个维度，对UPF的各个核心接口的进、出流量进行累计计数。

    • 包数 (Packets): 反映了UPF的转发处理压力 (pps)。
    • 字节数 (Octets): 反映了UPF的带宽吞吐压力 (bps)。

  • 场景化应用：电竞决赛的流量画像 在电竞决赛期间，运维团队通过监控UPF的流量，可以得到一幅清晰的“流量画像”：

    • GTP.InDataPktN3UPF (N3入口包数) 和 IP.N6OutLinkUsage (N6出口流量) 持续高位：反映了海量用户上行直播流的巨大压力。
    • IP.N6IncLinkUsage (N6入口流量) 和 GTP.OutDataPktN3UPF (N3出口包数) 同样巨大：反映了全球观众下行观赛流的汇聚。 通过将这些数据按S-NSSAI细分，可以精确计算出“电竞直播切片”所消耗的上下行流量，为容量规划和商业结算提供依据。

2.2 质量的考验：丢包与时延 (5.4.1.7 - 5.4.1.9, 5.4.4.1, 5.4.5, 5.4.7, 5.4.8)

光有流量不够，传输质量才是关键。

5.4.1.7 Incoming GTP Data Packet Loss in UPF over N3 (GTP.InDataPktPacketLossN3UPF) 5.4.1.8 Outgoing GTP Data Packet Loss

  • 深度解析： ...PacketLoss... 监控UPF自身或其相邻链路的丢包情况。
    • Incoming Loss: UPF通过检查从gNB收到的GTP包序列号，发现的丢包。这主要反映了N3接口承载网的质量问题。
    • Outgoing Loss: UPF发送往gNB的GTP包，但后续可能因为某种机制（如gNB的反馈）得知其丢失。这主要反映了UPF自身或N3接口承载网的问题。

5.4.1.9 Round-trip GTP Data Packet Delay (GTP.RttDelayN3…Mean/Dist) 5.4.5 GTP packets delay in UPF (GTP.DelayDlIn…Mean/Dist)

  • 深度解析: 时延是衡量UPF性能的另一核心指标。
    • Round-trip Delay (RTT, 往返时延): UPF通过发送GTP Echo Request并等待Echo Reply的方式，测量与gNB（N3接口）、其他UPF（N9接口）之间的网络往返时延。这主要反映了传输网络的时延。
    • Delay in UPF (UPF内部时延): 通过在UPF的入口和出口对同一个数据包打上时间戳，测量数据包在UPF内部的处理时延（包括排队、查表、转发、计费等）。这是衡量UPF设备自身性能的关键指标。

2.3 场景化诊断：“立交桥”的拥堵点

“幻影”的云游戏卡顿问题，如果不是承载网丢包，那么UPF的时延测量将是下一个重点排查对象。

  1. 检查GTP.RttDelayN3...: 如果RTT时延很高或抖动很大，说明gNB与UPF之间的传输网络存在问题。
  2. 检查GTP.DelayDlInPsaUpfMean: 如果RTT正常，但UPF的内部处理时延很高，说明是UPF自身成为了瓶颈。可能是：
    • CPU过载: UPF需要为每个数据包执行复杂的PDR/FAR/QER等N4规则匹配，高流量下可能导致CPU资源耗尽。
    • 缓冲区拥塞 (Bufferbloat): UPF内部的发送队列过长，导致数据包在离开UPF前经历了很长的排队时间。
    • 硬件转发性能不足: UPF的硬件转发平面（如NP/ASIC芯片）达到了其吞吐量上限。

通过这套“分段式”的时延和丢包测量，运维人员可以像做CT扫描一样，精确定位出数据平面上性能瓶颈的具体位置。

3. “立交桥”上的“收费站”：QoS Flow & Session 统计 (5.4.10)

UPF不仅是转发设备，更是QoS策略的最终执行点 (PEP, Policy Enforcement Point)。SMF下发的QoS规则，最终都在UPF上生效。

5.4.10.1 Mean number of QoS flows (UPF.MeanQosFlows.SNSSAI/.Dnn…) 5.4.10.2 Maximum number of QoS flows (UPF.MaxQosFlows…)

  • 深度解析: 这组测量与SMF侧的SessionNbr测量类似，但主体是UPF。它通过采样统计，得出由该UPF实例承载的并发QoS Flow的平均数和峰值数。
  • 关键过滤维度:
    • SNSSAI: 按切片统计。
    • DNN: 按数据网络名称统计。
    • InternalGroupID: 按5G VN虚拟专网用户组统计。
  • 场景化应用：精细化的容量管理 通过这些测量，运营商可以获得极为精细的UPF负载视图：
    • 这个UPF上总共承载了多少条业务流？
    • 其中，“物联网切片”承载了多少条？“车联网切片”又承载了多少条？
    • 访问“企业A内网”（特定DNN）的业务流有多少？
    • 属于“XX公安虚拟专网”用户组的业务流又有多少？ 这些数据是进行精细化容量规划、切片资源隔离验证以及虚拟专网性能监控的基础。

结论：UPF测量——5G用户面性能的“晴雨表”

作为5G数据平面的核心，UPF的性能直接决定了用户的最终体验。TS 28.552为我们提供了一套全面、立体的UPF性能测量体系。

  1. 控制面协同 (N4 Session): 确保了“交通规则”能够被正确、及时地下发和更新。
  2. 接口流量与质量 (N3/N6/N9): 从流量（包数/字节数）和质量（丢包/时延/乱序）两个维度，全面监控了“超级立交桥”的各个出入口和主干道的健康状况。
  3. 内部处理性能 (Delay in UPF): 通过测量内部处理时延，提供了透视UPF自身性能瓶颈的“X光片”。
  4. 业务承载规模 (QoS Flows): 通过对并发QoS Flow的精细化统计，为切片、专网等复杂业务场景下的容量管理提供了关键数据。

这套“晴雨表”式的测量体系，使得5G用户面的性能不再是一个“黑盒”。它让运维人员能够清晰地看到每一条数据流在UPF这座“超级立交桥”上的完整轨迹，从而快速定位拥堵、诊断故障，保障亿万用户的数据洪流平稳、高效地奔向目的地。

FAQ 环节

Q1：UPF和SMF是什么关系？为什么N4接口的测量会在5.3和5.4两章中都有定义？ A1：SMF是“大脑”，UPF是“手脚”。SMF负责所有与PDU会话相关的控制面决策，如IP地址分配、UPF选择、QoS策略制定等。UPF则是一个纯粹的用户面网元，它根据SMF通过N4接口下发的规则，对用户数据包进行转发、计费和QoS处理。 规范在两章中都定义N4测量，是因为它们是从**请求方（SMF）和响应方（UPF）**两个不同视角进行统计的，可以相互印证。例如，SMF统计的N4SessionModify请求数，应该等于UPF统计的（成功+失败）修改数，这有助于进行端到端的信令一致性校验。

Q2：GTP.RttDelayN3...（N3往返时延）和 GTP.DelayDlIn...（UPF内部时延）哪个更能反映UPF的设备性能？ A2：GTP.DelayDlInPsaUpfMean（UPF内部时延）更能直接反映UPF的设备性能。RttDelay测量的是一个包含UPF、gNB以及两者之间传输网络的端到端往返时延，其结果受传输网络质量影响很大。而Delay in UPF是通过对数据包进出UPF的时刻打时间戳计算得出的，它剥离了传输时延，纯粹衡量数据包在UPF内部因为排队、规则匹配、转发查找等操作所消耗的时间。

Q3：为什么UPF的流量统计要区分“包数”和“字节数”？ A3：因为它们反映了UPF不同层面的处理压力。“包数”（pps, packets per second）主要关联UPF的控制平面和处理性能。每个包都需要CPU或处理芯片进行一次查找和决策，高pps会对设备的计算资源造成巨大压力，容易导致时延增加。而**“字节数”（bps, bits per second）主要关联UPF的转发平面和链路带宽**。高bps会对设备的内部总线、接口带宽造成压力，容易导致拥塞和丢包。对于小包业务（如物联网、信令），pps压力是主要矛盾；对于大包业务（如视频下载），bps压力是主要矛盾。

Q4：5G中可以部署多个UPF吗？如何选择？ A4：可以，而且这是5G网络实现灵活性和低时延的关键。5G支持部署一个UPF池，SMF可以根据多种因素，为不同的PDU会话选择最合适的UPF，这个过程叫做UPF Selection。选择的依据可以包括：UE的位置（选择离UE最近的UPF以降低时延，即MEC场景）、UE请求的DNN（为访问企业内网选择专属的UPF）、UE签约的S-NSSAI（为特定切片选择专用的UPF）、UPF的负载情况等。

Q5：这些UPF的测量项，是否也支持虚拟化（VNF）部署形态？ A5：5.4节定义的这些测量，主要是针对UPF的通信功能本身，无论UPF是物理设备（PNF）还是虚拟机（VNF），这些测量都是适用的。但是，如果UPF是虚拟化的，那么它的性能还会受到底层虚拟资源（vCPU, vMemory, vNIC）的影响。在这种情况下，还需要结合我们之前在6.2节 Virtualised resource usage measurement中学到的测量项，对vUPF进行综合分析。例如，如果发现GTP.DelayDlInPsaUpfMean很高，同时VR.VCpuUsageMean也达到了100%，那么就可以判断，UPF的性能瓶颈是由于底层虚拟CPU资源不足导致的。

关系图谱