51学通信

深度解析 3GPP TS 28.552：5.1.1.13 QoS flow related measurements (QoS流相关测量)

21分钟阅读

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

深度解析 3GPP TS 28.552：5.1.1.13 QoS flow related measurements (QoS流相关测量)

本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中，关于“5.1.1.13 QoS flow related measurements”的核心章节，旨在为读者提供一个关于5G如何从无线侧视角监控业务服务质量（QoS）生命周期的全景解析。

引言：AR手术教学中的“VIP通道”保障

“王哥，智慧医院那边又来了新需求！”小林兴冲冲地跑来找老王，“他们准备在5G专网上开展AR（增强现实）手术教学。场景是这样的：主刀医生在手术室内操作，手术视野的高清视频流实时传输到教室，学生们戴着AR眼镜，能以第一视角看到主刀医生的视野，并且手术器械的关键参数会以AR标签的形式叠加在画面上。他们要求视频流绝对流畅，AR标签的刷新也必须和医生的动作同步。”

老王听完，沉思片刻：“这个场景对网络的要求非常高。它至少包含了两种截然不同的业务：一路是大带宽、持续性的GBR（保证比特率）高清视频流；另一路是小包、超低时延的AR交互数据流。这两路业务必须被严格区分对待，任何一方的服务质量下降都会导致教学失败。我们之前学的DRB测量，只能保证‘管道’通了，但无法保证管道里的‘水质’和‘流速’完全符合要求。”

他将TS 28.552的屏幕切换到5.1.1.13节。“今天，我们要把测量的精度，从‘管道级’（DRB）提升到‘水分子级’。在5G里，QoS Flow就是承载具体业务的最小粒度的数据流，它才是QoS策略的真正执行对象。这一节，‘QoS flow related measurements’，就是我们监控这些‘VIP通道’是否按照承诺提供了服务的‘质检报告’。通过它，我们能精确地知道，为AR视频流和AR标签流申请的QoS Flow，是否成功建立、是否稳定运行、以及在不再需要时是否被正常释放。”

这篇文章，我们将化身为“5G网络质检员”，以AR手术教学这个复杂场景为案例，深入剖析QoS Flow在gNB侧的全生命周期测量，理解5G精细化QoS保障体系的监控基石。

1. “VIP通道”的申请与开通：QoS Flow建立测量 (5.1.1.13.3)

当AR手术教学系统启动时，核心网的SMF会根据业务需求，向gNB发出指令，要求为视频流和AR标签流分别建立具有不同QoS特性的QoS Flow。这就像向网络申请开通两条不同等级的“VIP通道”。

1.1 开通申请单统计：Number of QoS flow attempted to setup (5.1.1.13.3.1)

a) This measurement provides the number of QoS flows attempted to setup. The measurement is split into subcounters per QoS level (5QI).

c) On receipt by the NG-RAN of a PDU SESSION RESOURCE SETUP REQUEST message, or receipt by the NG-RAN of a INITIAL CONTEXT SETUP REQUEST message, or receipt by the NG-RAN of a PDU SESSION RESOURCE MODIFY REQUEST message, each requested QoS flow in the message is added to the relevant measurement per QoS level (5QI) and per S-NSSAI…

e) QF.EstabAttNbr.5QI where 5QI identifies the 5QI and QF.EstabAttNbr.SNSSAI identifies the S-NSSAI.

1.1.1 深度解析

  • 测量对象: QF.EstabAttNbr (QoS Flow, Establishment Attempt Number) 统计gNB收到了多少次QoS Flow的建立请求。它是从比DRB更细的粒度，来衡量网络的业务接入请求量。
  • 触发条件: 当gNB从AMF收到的三大核心资源配置消息（INITIAL CONTEXT SETUP REQ, PDU SESSION RESOURCE SETUP REQ, PDU SESSION RESOURCE MODIFY REQ）中，包含了需要新增的QoS Flow列表时，gNB会遍历这个列表，每有一个QoS Flow，对应的计数器就加1。
  • 核心过滤维度: 这个测量最重要的就是按 5QI (5G QoS Identifier) 进行细分。5QI是标识QoS Flow服务质量等级的“身份证号”。例如：
    • 5QI = 1: GBR, 用于VoNR等会话语音
    • 5QI = 8: Non-GBR, 用于交互式游戏
    • 5QI = 83: GBR, 用于实时视频流
    • 5QI = 82: GBR, 用于低时延uRLLC业务 当然，它也支持按S-NSSAI（网络切片）细分。

1.1.2 场景化举例：为AR手术建立双通道

AR手术教学系统启动时，核心网为“鹰眼-Pro”的视频流（5QI=83）和AR标签流（假设为uRLLC业务，5QI=82）同时发起了QoS Flow建立请求。gNB收到消息后：

  • QF.EstabAttNbr.5QI_83 子计数器加1。
  • QF.EstabAttNbr.5QI_82 子计数器加1。

“小林你看，”老王指出，“通过这两个子计数器，我们就精确地知道了，医院专网中，高清视频和超低时延控制这两类核心业务的发起频率。这是分析业务模型、评估网络压力的第一手资料。”

1.2 开通成功/失败回执：Number of QoS flow successfully established/failed to setup (5.1.1.13.3.2 & 5.1.1.13.3.3)

gNB收到请求后，会尝试为这些QoS Flow分配资源（可能是新建DRB，也可能是映射到现有DRB），并将结果回复给核心网。

5.1.1.13.3.2 Number of QoS flow successfully established c) On transmission by the NG-RAN of a … RESPONSE message, each QoS flow successfully established is added to the relevant measurement per QoS level (5QI)… e) QF.EstabSuccNbr.5QI…

5.1.1.13.3.3 Number of QoS flow failed to setup c) On transmission by the NG-RAN of a … RESPONSE message, each QoS flow failed to establish is added to the relevant measurement per cause… e) QF.EstabFailNbr.Cause

  • 深度解析: QF.EstabSuccNbr (Success) 和 QF.EstabFailNbr (Failure) 分别统计成功和失败的QoS Flow数量。

    • 成功 (Succ): 当gNB在给AMF的RESPONSE消息中，确认某个QoS Flow已经成功建立时，按5QI计数的Succ计数器加1。
    • 失败 (Fail): 当gNB在RESPONSE消息中，上报某个QoS Flow建立失败时，按失败原因 (Cause) 计数的Fail计数器加1。失败原因与PDU会话和DRB建立失败的原因类似，如radio-resources-not-available等。

  • 场景化举例：QoS Flow建立成功率KPI QoS Flow建立成功率 (per 5QI) = (QF.EstabSuccNbr.5QI_X / QF.EstabAttNbr.5QI_X) * 100%

    小林查看医院专网数据，发现5QI=83（视频流）的建立成功率是99.9%，非常健康。但5QI=82（AR标签流）的成功率只有95%。他进一步查看QF.EstabFailNbr.Cause的分布，发现失败原因主要是invalid-qos-combination。

    “王哥，这说明gNB认为核心网下发的5QI=82的QoS参数组合无效。这很可能是gNB侧的QoS参数模板没有正确配置，不认识或者不支持核心网要求的超低时延参数！”

    “诊断非常准确！”老王赞许道，“这就是QoS Flow级别测量的威力。如果是DRB测量，我们可能只看到一个DRB建立失败，但不知道是里面哪个QoS Flow出了问题。现在，我们可以精准地告诉后台配置人员，去检查gNB上关于5QI=82的配置。”

2. “VIP通道”的生命体征：QoS Flow活动与释放测量

通道开通后，还需要监控它的使用情况和生命周期，确保其稳定运行，并在不需要时能被及时回收。

2.1 通道活跃时长统计：In-session activity time for QoS flow (5.1.1.13.2.1)

a) This measurement provides the aggregated active session time for QoS flow in a cell. c) Number of “in session” seconds aggregated for QoS flows with a certain QoS level…

  • 深度解析: QF.SessionTimeQoS.QoS 与 DRB.SessionTime 的原理完全相同，但统计粒度细化到了每个QoS Flow。它按5QI分别统计不同业务流的“总在线时长”，是评估业务活跃度和资源占用时长的直接依据。

2.2 异常中断告警：Number of released active QoS flows (5.1.1.13.1.1)

这是衡量业务可靠性的终极指标，用于计算QoS Flow掉线率。

a) This measurement provides the number of released QoS flows that were active at the time of release… The measurement is split into subcounters per QoS level. c) On transmission by the NG-RAN of a PDU SESSION RESOURCE RELEASE RESPONSE message… with the exception of “Normal Release” or “User inactivity”… e) The measurement name has the form QF.RelActNbr.QoS.

  • 深度解析: QF.RelActNbr (Released Active Number) 的逻辑与DRB.RelActNbr完全一致，采用“排除法”，只统计那些在激活状态下、由于异常原因被释放的QoS Flow。 这个指标的可怕之处在于，它的每一次增长，都直接对应着一次用户正在进行的业务（一次通话、一场游戏、一次手术直播）的突然中断。

  • 场景化举例：QoS Flow掉线率KPI QoS Flow掉线率 (per 5QI) = QF.RelActNbr.5QI_X / (某周期内总的发起次数) (分母需要结合其他计数器综合计算)

    如果医院专网的运维人员发现，QF.RelActNbr.QoS_82（AR标签流）的计数器偶尔会有跳动，即使只有一两次，也需要引起高度警惕。因为这意味着支撑手术关键数据显示的“VIP通道”发生了瞬断，这在真实手术中是不可接受的。通过关联该时刻的其他网络指标（如无线信号、干扰、传输网告警），就能找到造成掉线的根本原因。

2.3 资源回收监控：Number of QoS flows attempted to release (5.1.1.13.1.2)

a) This measurement provides the number of QoS flows attempted to release.

  • 深度解析: QF.ReleaseAttNbr.5QI 统计网络（包括gNB自身或核心网）总共发起了多少次QoS Flow的释放请求，无论正常还是异常。这个指标与成功释放的计数器（规范中未直接定义，但可由后台推算）结合，可以评估网络资源回收的效率。如果请求释放的很多，但实际没有释放掉（“僵尸”QoS Flow），就会造成资源泄露。

3. “VIP通道”的升级改造：QoS Flow修改测量 (5.1.1.13.4)

在AR手术过程中，可能会出现需要动态调整QoS的场景。例如，当检测到网络拥塞时，为了优先保证AR标签的超低时延，可以适当降低视频流的带宽。这个过程就是QoS Flow Modification。

5.1.1.13.4.1 Number of QoS flows attempted to modify (QF.ModNbrAtt.5QI) 5.1.1.13.4.2 Number of QoS flows successfully modified (QF.ModNbrSucc.5QI) 5.1.1.13.4.3 Number of QoS flows failed to modify (QF.ModNbrFail.cause)

  • 深度解析与场景应用: 这组测量监控了QoS Flow修改的完整流程：

    1. 当gNB收到核心网发来的PDU SESSION RESOURCE MODIFY REQUEST，其中包含对某个QoS Flow的修改请求时，QF.ModNbrAtt.5QI加1。
    2. 如果gNB成功执行了修改（如调整了DRB配置），并在响应消息中确认，则QF.ModNbrSucc.5QI加1。
    3. 如果修改失败，则QF.ModNbrFail.cause按失败原因加1。

    QoS Flow修改成功率是衡量网络动态策略执行能力的重要指标。在未来的智能化网络中，NWDAF（网络数据分析功能）可能会频繁地根据网络状况，建议SMF动态调整QoS Flow参数。这组测量的性能，将直接决定了网络“智能大脑”的指令能否被有效执行。

结论：QoS Flow测量——5G服务质量的“最后一道防线”

通过对AR手术教学场景的深入分析，我们看到，QoS Flow相关的测量，构成了5G QoS保障体系中最为精细、也最为关键的监控环节。

  1. 粒度最细: 它直接面向最终的业务流，能够区分同一用户、同一PDU会话下的不同业务，实现真正的差异化服务监控。
  2. 生命周期完整: 从建立、活动、修改到释放，覆盖了QoS Flow的全生命周期，提供了从接入性、可靠性到灵活性的端到端视图。
  3. 诊断精准: 无论是建立失败还是异常掉线，按5QI和Cause细分的子计数器都能将问题直接定位到具体的业务类型和故障根源。

如果说RRC连接是“准入控制”，DRB是“管道工程”，那么QoS Flow就是管道中为不同用户输送“纯净水”、“矿泉水”甚至“特供营养液”的精细化阀门系统。5.1.1.13节的测量，就是监控这套精密阀门系统是否正常工作的“水质与流速传感器”，是保障5G千行百业差异化、确定性服务的最后一道防线。

FAQ 环节

Q1：QoS Flow和5QI是什么关系？它们和4G时代的EPS Bearer、QCI有什么区别？ A1：QoS Flow是5G QoS架构的基本粒度，是IP包在5G网络中被同等对待的一个数据流。5QI是QoS Flow的一个核心属性，它是一个标量，代表了一组QoS特性（如资源类型GBR/Non-GBR、优先级、时延预算、错误率等）。可以理解为，5QI是“服务等级”，QoS Flow是应用了这个“服务等级”的一条具体“业务流”。 与4G相比，这是一个根本性的变革。4G的QoS单位是EPS Bearer，它是一个“隧道”，QoS属性（由QCI定义）是绑定在这个隧道上的。一个用户一种业务通常一个Bearer。而5G将业务流（QoS Flow）和承载隧道（DRB）进行了解耦，多个QoS Flow可以动态映射到一个DRB上。这种“流”模型比“隧道”模型更加灵活、高效，能够支持更精细、更多样的业务并发。

Q2：为什么一个QoS Flow的建立和释放，是由PDU Session相关的信令（如PDU SESSION RESOURCE MODIFY REQUEST）来承载的？ A2：因为QoS Flow是“寄生”在PDU会话之上的。一个PDU会话定义了UE与一个特定数据网络（DN）之间的IP连接。在这个连接的“总管道”内，可以存在多条具有不同QoS特性的“子管道”，也就是QoS Flow。因此，对QoS Flow的所有操作（增加、删除、修改），都被视为对所属PDU会话资源的一次“修改”（Modification），所以由PDU Session相关的信令来承载，这是符合其逻辑层级关系的。

Q3：如果一个gNB不支持核心网下发的某个5QI，会发生什么？哪个测量项会反映这个问题？ A3：如果gNB不支持（例如，没有配置相关参数模板）核心网请求建立的某个5QI，gNB会在给AMF的RESPONSE消息中，将这个QoS Flow列入“建立失败列表”，并附上失败原因。此时，5.1.1.13.3.3 Number of QoS flow failed to setup (QF.EstabFailNbr.Cause) 这个测量项的对应子计数器就会增加。最可能的原因是invalid-qos-parameter或类似的协议原因。这通常指向了核心网与无线网之间配置不一致的问题。

Q4：QF.RelActNbr (QoS Flow异常掉线数) 和 DRB.RelActNbr (DRB异常掉线数) 哪个更能准确反映用户业务中断？ A4：QF.RelActNbr更能直接和精确地反映用户业务中断。一个DRB上可能承载了多个QoS Flow。当这个DRB异常掉线时，DRB.RelActNbr只计数1次，但实际上可能导致了多个业务（QoS Flow）的同时中断，此时QF.RelActNbr会根据中断的QoS Flow数量进行多次计数。此外，有些异常可能只导致DRB内的某个QoS Flow被释放，而DRB本身还存在，这种情况只有QF.RelActNbr能捕获到。因此，QF.RelActNbr是衡量业务级可靠性的更精准的指标。

Q5：这些QoS Flow测量在NSA（非独立组网）架构下是否适用？ A5：在典型的EN-DC（E-UTRA NR Dual Connectivity）NSA架构下，QoS的管理模型与SA有很大不同。在EN-DC下，QoS的主控点在4G核心网（EPC）和主基站（MeNB）。业务的承载是EPS Bearer。5G gNB（作为辅站，SgNB）只是被动地接收从主站分流过来的数据，它看到的承载是Split Bearer或SCG Bearer，但它本身不直接处理5G核心网下发的QoS Flow。因此，TS 28.552中定义的这套基于5QI和QoS Flow的测量体系，主要适用于5G SA（独立组网） 架构。NSA网络的QoS性能测量需要更多地参考4G的测量规范（如TS 32.425中关于E-RAB的测量）。

关系图谱