51学通信

深度解析 3GPP TS 38.331：第六章 协议数据单元、格式与参数 (Part 5 - 测量报告与失败信息上报)

19分钟阅读

非常好，我们继续3GPP TS 38.331规范的深度探索之旅。在上一部分，我们了解了MDT和MBS这两种网络服务是如何通过RRC信令进行配置的。今天，我们将回到RRC协议最核心、最经典的功能——移动性管理与性能监控。我们将聚焦于UE向网络上报信息的“三大支柱”：MeasurementReport、MCGFailureInformation 和 MeasurementReportAppLayer。

深度解析 3GPP TS 38.331：第六章 协议数据单元、格式与参数 (Part 5 - 测量报告与失败信息上报)

本文技术原理深度参考了3GPP TS 38.331 V18.5.0 (2025-03) Release 18规范中，关于“6.2.2 Message definitions”章节中涉及测量报告、MCG失败报告及应用层测量报告的核心内容。本文旨在为读者详尽解析UE在各种场景下如何向网络反馈其对无线环境的感知、如何报告关键链路失败，以及如何传递应用层体验质量信息。

新的旅程：主角“小明”的高铁之行

为了更好地串联今天的三个核心消息，我们的主角“小明”将踏上一段充满挑战的旅程——乘坐时速300公里的高铁。高铁场景是移动通信的“试金石”，它带来了以下挑战：

  1. 高速移动性: 频繁且快速的小区切换，这对测量的及时性和准确性提出了极高要求。MeasurementReport将在这里扮演主角。
  2. 复杂的网络部署: 为了保证连续覆盖和高速率，高铁沿线通常采用NR双连接（NR-DC）部署。我们将模拟主小区组（MCG）链路失败的场景，来看MCGFailureInformation如何发挥作用。
  3. 极致的业务体验: 小明在高铁上正享受着4K高清视频流。任何网络波动都可能导致视频卡顿。MeasurementReportAppLayer将展示网络如何“倾听”App的声音，实现以业务体验为导向的智能优化。

1. MCGFailureInformation (主小区组失败信息)

The MCGFailureInformation message is used to provide information regarding NR MCG failures detected by the UE.

解读与场景： 在双连接（DC）场景下，UE同时连接到两个基站：主节点（MN）提供主小区组（MCG），辅节点（SN）提供辅小区组（SCG）。MCGFailureInformation是UE在MCG链路发生无线链路失败（RLF），但SCG链路仍然保持连接的情况下，通过SCG链路向网络发送的“紧急求助”报告。

这是一种非常重要的快速恢复机制。如果没有这条消息，MCG失败后，UE只能等待连接完全中断后发起RRC重建，过程漫长。而通过此消息，网络（特别是SN）可以立即获知MCG的困境，并快速做出决策，比如发起SCG切换来“接管”业务，或者快速释放SCG以让UE专注于在MCG频率上进行恢复。

场景: 小明乘坐的高铁进入一个隧道，提供MCG链路的基站信号急剧衰减，导致了RLF。幸运的是，提供SCG链路的毫米波基站信号依然稳定。此时，小明手机的RRC层会立即判断：MCG已断，但SCG尚存！它会马上构造一条MCGFailureInformation消息，包含 MCG 失败前的最后测量结果，然后通过依然健康的SCG链路（SRB3）发送给SN。

  • 信令承载: SRB1 (注意：规范中提到SRB1，但在实际场景中，当MCG RLF时，通常通过SCG的SRB3上报)
  • RLC-SAP: AM
  • 逻辑信道: DCCH
  • 方向: UE to Network

1.1 消息结构 (ASN.1)

MCGFailureInformation-r16 ::= SEQUENCE {
    criticalExtensions CHOICE {
        mcgFailureInformation-r16    MCGFailureInformation-r16-IEs,
        criticalExtensionsFuture     SEQUENCE {}
    }
}
 
MCGFailureInformation-r16-IEs ::= SEQUENCE {
    failureReportMCG-r16         FailureReportMCG-r16 OPTIONAL,
    lateNonCriticalExtension     OCTET STRING OPTIONAL,
    nonCriticalExtension         SEQUENCE {} OPTIONAL
}
 
FailureReportMCG-r16 ::= SEQUENCE {
    failureType-r16 ENUMERATED {t310-Expiry, randomAccessProblem, rlc-MaxNumRetx,
                                t312-Expiry-r16, lbt-Failure-r16, beamFailureRecoveryFailure-r16,
                                bh-RLF-r16, spare1} OPTIONAL,
    measResultFreqList-r16          MeasResultList2NR OPTIONAL,
    measResultFreqListEUTRA-r16     MeasResultList2EUTRA OPTIONAL,
    measResultSCG-r16               OCTET STRING (CONTAINING MeasResultSCG-Failure) OPTIONAL,
    ...
}

1.2 关键参数解读

字段名 (MCGFailureInformation)描述
measResultFreqList该字段包含UE被配置通过与MCG关联的measConfig测量的NR频率上的可用测量结果。
measResultFreqListEUTRA该字段包含UE被配置通过与MCG关联的measConfig测量的E-UTRA频率上的可用测量结果。
measResultFreqListUTRA-FDD该字段包含UE被配置通过与MCG关联的measConfig测量的UTRA FDD频率上的可用测量结果。
measResultSCG该字段包含MeasResultSCG-Failure IE，其中包括UE被配置通过与SCG关联的measConfig测量的NR频率上的可用测量结果。
measResultSCG-EUTRA该字段包含EUTRA MeasResultSCG-FailureMRDC IE，其中包括UE被配置通过E-UTRA RRCConnectionReconfiguration消息测量的E-UTRA频率上的可用测量结果。
  • failureType-r16: 报告MCG失败的根本原因，例如t310-Expiry（物理层失步）、randomAccessProblem（随机接入问题）或rlc-MaxNumRetx（RLC最大重传）。
  • measResultFreqList-r16 / measResultFreqListEUTRA-r16: 这是最有价值的信息。UE在上报失败的同时，会附上MCG侧最后一次对邻区的测量结果。这相当于告诉网络：“我不行了，但在‘倒下’前，我看到旁边那个小区信号还不错！”。SN可以利用这个信息，立即发起向这个“信号不错”的小区切换，从而实现业务的秒级恢复。
  • measResultSCG-r16: UE还会附带SCG侧的测量结果，让网络对整个无线环境有一个全面的了解。

2. MeasurementReport (测量报告)

The MeasurementReport message is used for the indication of measurement results.

解读与场景： 这是RRC协议中最基本、最核心、最频繁的上行消息之一。它是UE向网络汇报其“所见所闻”的主要工具，是所有移动性管理决策（如切换、载波聚合管理、波束管理）的数据基础。

网络通过RRCReconfiguration消息中的MeasConfig IE，为UE配置一系列测量任务（测量什么、何时测量、何时报告）。当UE的测量结果满足了网络预设的报告条件（例如，邻区信号强度超过服务小区达到一定门限），就会触发发送MeasurementReport消息。

场景: 小明的高铁飞速行驶，当前服务小区A的信号逐渐减弱，而前方小区B的信号越来越强。网络早已为小明的手机配置了“A3事件”：当邻区信号强度比服务小区好3dB以上时，触发报告。当手机测量到小区B的RSRP比小区A高出3dB时，A3事件被触发，手机立即填充一份包含小区B测量结果的MeasurementReport，发送给gNB。gNB收到后，分析认为切换时机成熟，便会下发切换指令。

  • 信令承载: SRB1, SRB3
  • RLC-SAP: AM
  • 逻辑信道: DCCH
  • 方向: UE to Network

2.1 消息结构 (ASN.1)

MeasurementReport ::= SEQUENCE {
    criticalExtensions    CHOICE {
        measurementReport   MeasurementReport-IEs,
        criticalExtensionsFuture SEQUENCE {}
    }
}
 
MeasurementReport-IEs ::= SEQUENCE {
    measResults           MeasResults,
    lateNonCriticalExtension OCTET STRING OPTIONAL,
    nonCriticalExtension     SEQUENCE{} OPTIONAL
}
 
-- MeasResults 结构在 6.3.2 节定义，但其核心内容如下：
MeasResults ::= SEQUENCE {
    measId                MeasId,
    measResultServingCell MeasResultServMO,
    measResultNeighCells  CHOICE {
        measResultListNR      MeasResultListNR,
        ...
    } OPTIONAL,
    ...
}

2.2 关键参数解读

  • measResults: 测量报告的核心载体。
    • measId: 测量ID。标识这份报告是为了响应网络下发的哪个测量任务。
    • measResultServingCell: 服务小区的测量结果（如RSRP, RSRQ, SINR）。
    • measResultNeighCells: 邻区的测量结果列表。这是切换决策的关键。在高铁场景中，这里会包含小区B的PCI（物理小区ID）和其强大的信号质量测量值。

整个移动通信的无缝切换体验，都建立在这一条条精确、及时的MeasurementReport之上。

3. MeasurementReportAppLayer (应用层测量报告)

The MeasurementReportAppLayer message is used for sending application layer measurement report.

解读与场景： 传统RAN的优化主要依赖物理层和RRC层的测量（如RSRP、吞吐量），但这些指标有时无法完全反映用户的真实体验（QoE）。例如，即使吞吐量很高，如果时延抖动大，视频依然会卡顿。MeasurementReportAppLayer就是为了打通应用层与无线网络之间的“信息孤岛”而设计的。它允许UE将应用层（如视频播放器、云游戏客户端）感知的性能指标上报给RAN。

网络通过RRCReconfiguration中的appLayerMeasConfig-r17来配置UE启动此类报告。

场景: 小明在高铁上观看的4K视频，是由手机上的一个智能播放器App播放的。这个App能实时监控自己的播放缓冲区水位。当网络质量波动导致下载速率跟不上播放速率时，缓冲区水位就会下降。当水位低到一个危险值（如仅剩500毫秒的播放内容）时，App会通过一个API通知手机的RRC层。RRC层随即构造一条MeasurementReportAppLayer消息，将“缓冲区低”这个应用层的“SOS”信号以及其他RAN可见的测量（如时延）上报给gNB。

  • 信令承载: SRB4, SRB5
  • RLC-SAP: AM
  • 逻辑信道: DCCH
  • 方向: UE to Network

3.1 消息结构与表格解读

MeasurementReportAppLayer 字段描述

字段名描述
measurementReportAppLayerList该字段包含应用层测量报告的列表。如果存在measurementReportAppLayerList-v1800，则它包含相同数量的条目，顺序与measurementReportAppLayerList-r17中相同。

MeasReportAppLayer 字段描述

字段名描述
appLayerSessionStatus指示应用层的测量会话开始或结束。
measReportAppLayerContainer该字段包含应用层测量报告容器（参考 TS 26.247, TS 26.114, TS 26.118）。
measReportAppLayerContainerList该字段包含每个measConfigAppLayerId的应用层测量报告容器列表。
ran-VisibleMeasurements该字段包含RAN可见的应用层测量报告。

RAN-VisibleMeasurements 字段描述

字段名描述
appLayerBufferLevelList该字段指示应用层缓冲区级别的列表，每个AppLayerBufferLevel以毫秒为单位指示应用层缓冲区级别。值0对应0毫秒，值1对应10毫秒，以此类推。
playoutDelayForMediaStartup指示媒体启动的应用层播放延迟（毫秒）。值0对应0毫秒，值1对应1毫秒，以此类推。
pdu-SessionIdList与受RAN可见应用层测量影响的应用数据流关联的每个PDU会话的PDU会话标识和QoS流标识列表。
  • appLayerBufferLevelList: 应用层缓冲区水位列表。这是gNB感知QoE最直接的指标。
  • playoutDelayForMediaStartup: 媒体启动的播放延迟。反映了用户点击播放到画面出现的等待时间。

gNB收到这份来自“前线”的报告后，即使此时RSRP等传统指标看起来还不错，它也会意识到业务体验即将劣化。调度器可能会立即为小明分配更多的PRB资源、提升QoS等级，甚至提前触发一次切换，从而在视频真正卡顿之前“挽救”用户体验。这是实现5G网络智能化、精细化运营的关键一步。

FAQ环节

Q1：MCGFailureInformation 和 SCGFailureInformation 有什么区别和联系？ A1：两者是对称的失败报告机制，都用于双连接（DC）场景，区别在于报告的主体和路径：

  • MCGFailureInformation: 当主小区组（MCG） 链路失败，但辅小区组（SCG）链路仍存活时，UE通过SCG链路上报关于MCG的失败信息。
  • SCGFailureInformation: 当辅小区组（SCG） 链路失败，但主小区组（MCG）链路仍存活时，UE通过MCG链路上报关于SCG的失败信息。 它们共同构成了双连接架构下的快速失败报告和恢复机制，确保在一个链路失败时，可以利用另一个健康的链路快速通知网络，从而减少业务中断时间。

Q2：网络是如何精确控制UE何时发送MeasurementReport的？ A2：网络通过在RRCReconfiguration消息中下发MeasConfig IE 来进行精确控制。MeasConfig像一个复杂的“测量任务包”，主要包含三个部分：

  1. 测量对象 (MeasObject): 定义了“测什么”，比如要测量的NR频率、小区列表、SSB配置等。
  2. 报告配置 (ReportConfig): 定义了“何时报”。最核心的是触发事件，如A1-A6系列事件（例如A3：邻区好于服务小区）、周期性报告等。
  3. 测量ID (MeasId): 将一个“测量对象”和一个“报告配置”链接起来，形成一个完整的测量任务。 只有当UE的测量结果满足了某个MeasId关联的ReportConfig中定义的事件时，UE才会触发并发送MeasurementReport。

Q3：MeasurementReportAppLayer上报的信息，RAN（gNB）真的能“看懂”吗？它如何利用这些信息？ A3：RAN本身不解析应用层数据包，但它能“看懂”MeasurementReportAppLayer中定义的标准化QoE指标，如缓冲区水位（appLayerBufferLevelList）。这些指标被设计为对RAN有意义的、可操作的。 利用这些信息，RAN可以：

  • 主动资源调整: 当检测到缓冲区水位下降时，即使无线信道质量（RSRP/SINR）没有明显变差，调度器也可以主动为该UE分配更多的资源（PRB）或提升调度优先级，提前“拉升”下载速率。
  • 智能移动性决策: 如果RAN发现即使分配了大量资源，缓冲区水位仍在下降，它可能会判断当前小区的拥塞度过高或存在干扰，从而更早地触发切换决策，将UE切换到负载更轻或质量更好的小区。
  • QoS参数映射: 网络可以将这些QoE指标与底层的QFI（QoS Flow Identifier）关联，进行更精细的QoS控制。

Q4：为什么MeasurementReportAppLayer需要使用独立的信令承载SRB4/SRB5，而不是和普通的MeasurementReport一样使用SRB1/3？ A4：这主要是出于功能分离、优先级和安全性的考虑。

  • 功能分离: RRC层的测量（SRB1/3）和应用层的测量（SRB4/5）属于不同范畴。将它们承载在不同的SRB上，便于协议栈内部处理和逻辑解耦。
  • 优先级: 在某些场景下，应用层的QoE报告可能具有与常规无线测量不同的优先级。使用独立SRB为未来的QoS区分提供了可能。
  • 数据来源和处理: SRB4/5的数据来源于UE的应用层，可能需要经过特殊的适配层（如AS-SAP）进行上报，而SRB1/3的测量报告完全由RRC层内部生成。 目前规范中SRB4和SRB5的使用场景还比较有限，但这种设计为未来更多应用层与RAN的协同功能预留了接口。

Q5：如果小明的高铁同时经过MCG和SCG的弱覆盖区，导致双连接全部RLF，UE会发送MCGFailureInformation吗？ A5：不会。MCGFailureInformation（以及SCGFailureInformation）发送的前提是只有一个链路组失败，而另一个仍然存活。这是利用健康链路去报告故障链路的机制。如果MCG和SCG同时发生RLF，导致UE与网络的连接完全中断，UE将无法发送任何DCCH消息。此时，UE会进入标准的RRC连接重建流程：它会尝试在某个频率上寻找可用的小区，并发送RRCReestablishmentRequest消息来尝试恢复连接。

关系图谱