好的，我们继续跟随工程师阿哲的脚步，深入探索3GPP TS 38.331规范。至此，我们已经完成了对RRC协议最核心、最庞大的5.3节（连接控制）和5.4节（异系统移动性）的深度剖析。阿哲的手机，在他的理论世界里，已经能够熟练地建立连接、处理各种复杂的移动和连接场景。

现在，阿哲决定将目光转向一个同样至关重要的领域——测量（Measurements）。在之前的章节中，我们多次提到“测量报告”是驱动切换等移动性流程的关键。但网络是如何精确地告诉UE“测什么”、“何时测”、“怎么报”的呢？UE在收到这些指令后，又是如何执行测量、处理数据，并最终决定触发上报的呢？

所有这些问题的答案，都隐藏在规范的5.5节——“Measurements”之中。这一章节是RRC移动性管理和网络优化的“感知系统”和“数据中枢”。本篇文章，我们将聚焦于测量的基础框架和配置流程，深入解读5.5.1节到5.5.2节，揭示RRC是如何通过“三驾马车”——测量对象、报告配置和测量ID——来构建一个灵活、强大且可扩展的测量体系。

---

深度解析 3GPP TS 38.331：5.5.1 & 5.5.2 测量的艺术：RRC的“三驾马车”模型

本文技术原理深度参考了3GPP TS 38.331 V18.5.1 (2025-03) Release 18规范中，关于“5.5.1 Introduction”和“5.5.2 Measurement configuration”的核心章节，旨在为读者全面剖析RRC测量框架的顶层设计，以及通过measConfig进行测量对象、报告配置和测量ID的增删改查的完整流程。

1. 测量的“世界观”：RRC测量框架简介 (解读5.5.1 Introduction)

阿哲知道，任何复杂的系统都源于一个清晰的顶层设计。5.5.1节就为我们描绘了RRC测量的宏观世界观。

The network may configure an RRC_CONNECTED UE to perform measurements. The network may configure the UE to report them in accordance with the measurement configuration… The measurement configuration is provided by means of dedicated signalling i.e. using the RRCReconfiguration or RRCResume.

这段话明确了测量的基本前提：

• 执行者：RRC_CONNECTED状态的UE。

• 指挥者：网络（gNB）。

• 指挥方式：通过专用信令RRCReconfiguration或RRCResume下发测量配置。

接下来，规范定义了UE可以执行的测量类型和上报的测量信息，种类繁多，体现了5G网络精细化运营的需求。

测量类型:

• NR measurements (NR内部测量)

• Inter-RAT measurements of E-UTRA frequencies (对4G的测量)

• Inter-RAT measurements of UTRA-FDD frequencies (对3G的测量)

• NR sidelink measurements of L2 U2N Relay UEs (对Sidelink中继的测量)

上报信息:

• 基于SS/PBCH block的测量结果（小区级/波束级）

• 基于CSI-RS的测量结果（小区级/波束级）

• Sidelink的CBR（信道繁忙率）测量

• 基于SRS的CLI（跨链路干扰）测量

• 基于CLI-RSSI的CLI测量

• UE Rx-Tx时间差测量

1.1 RRC测量的核心“三驾马车”

在如此繁多的测量类型和信息中，RRC通过一个优雅的抽象模型来组织它们，这就是著名的“三驾马车”模型。

The measurement configuration includes the following parameters:

1. Measurement objects: A list of objects on which the UE shall perform the measurements.

2. Reporting configurations: A list of reporting configurations where there can be one or multiple reporting configurations per measurement object.

3. Measurement identities: …a list of measurement identities where each measurement identity links one measurement object with one reporting configuration.

阿哲立刻用一个生动的比喻来理解这个模型：

• Measurement Object (测量对象): “测什么？”

  • 它定义了一个具体的测量目标。例如，“测量频点为N78的载波上的SSB信号”，或者“测量频点为B3的LTE载波”。一个measObject包含频率、子载波间隔、测量带宽、小区列表（黑名单/白名单）、测量时窗（SMTC）等物理参数。

• Reporting Configuration (报告配置): “何时报？怎么报？”

  • 它定义了触发测量报告的规则和报告的格式。例如，“当邻区信号比服务小区好3dB时，上报一次报告，报告中包含最强的3个邻区的RSRP和RSRQ值”。一个reportConfig包含触发类型（周期性/事件触发）、触发事件（A1-A6等）、报告量、报告间隔等规则参数。

• Measurement Identity (测量ID): “把‘测什么’和‘怎么报’联系起来”

  • 它像一条纽带，将一个measObject和一个reportConfig唯一地链接在一起，形成一个完整的、可执行的测量任务。measId本身只是一个ID号，但它在测量报告中被引用，让网络知道这份报告是由哪个测量任务触发的。

这种“解耦”的设计带来了极大的灵活性：

• 重用性：同一个measObject（如测量N78频点）可以被多个reportConfig链接，用于不同的目的（例如，一个用于切换，一个用于周期性上报）。

• 灵活性：同一个reportConfig（如事件A3）可以被用于多个measObject，对不同的频点应用相同的切换策略。

2. 动态调整“侦察任务”：测量配置流程 (解读5.5.2 Measurement configuration)

网络对UE的测量配置并非一成不变，而是会根据UE的位置、业务类型等动态调整。RRCReconfiguration消息中的measConfig IE就是实现这种动态调整的载体。

5.5.2.1 General

The UE shall:

1> if the received measConfig includes the measObjectToRemoveList:

2> perform the measurement object removal procedure as specified in 5.5.2.4;

1> if the received measConfig includes the measObjectToAddModList:

2> perform the measurement object addition/modification procedure as specified in 5.5.2.5;

… (similarly for reportConfig and measId)

measConfig IE本身就像一个“配置变更单”，它不包含完整的测量配置，而是通过“增/删/改”列表的方式，对UE当前的测量配置进行修改。

2.2.1 删除测量ID (5.5.2.2 Measurement identity removal)

当网络认为某个测量任务不再需要时，会在measIdToRemoveList中列出要删除的measId。

1> for each measId included in the received measIdToRemoveList…:

2> remove the entry with the matching measId from the measIdList within the VarMeasConfig;

2> remove the measurement reporting entry for this measId from the VarMeasReportList, if included;

2> stop the periodical reporting timer or timer T321 or timer T322…

UE收到后，会：

1. 从其measIdList中删除该ID。

2. 停止与该ID关联的任何定时器（如周期上报定时器）。

3. 清除与该ID相关的任何已触发但未上报的状态信息（如已进入事件的邻区列表）。

2.2.2 添加/修改测量ID (5.5.2.3 Measurement identity addition/modification)

当网络需要新增或修改一个测量任务时，会在measIdToAddModList中提供measId及其关联的measObjectId和reportConfigId。

1> for each measId included in the received measIdToAddModList:

2> if an entry with the matching measId exists in the measIdList…:

3> replace the entry with the value received for this measId;

2> else:

3> add a new entry for this measId to the measIdList...

• 如果该measId已存在，UE会更新其关联的measObjectId或reportConfigId。

• 如果measId是全新的，UE则会创建一个新的测量任务。

一个值得注意的细节是，如果某个reportConfig的触发类型是reportCGI（请求UE上报小区的全球唯一标识CGI），UE会启动一个T321定时器。如果在规定时间内无法获取CGI，流程会超时。

2.2.3 测量对象的增删改查 (5.5.2.4 & 5.5.2.5)

对测量对象（MeasObject）的操作同样是通过measObjectToRemoveList和measObjectToAddModList完成的。

• 删除测量对象：当一个measObjectId被删除时，所有与之关联的measId也必须被级联删除。这是一个重要的连锁反应，确保了不会有“悬空”的测量任务存在。

  2> remove all measId associated with this measObjectId from the measIdList within the VarMeasConfig, if any;

• 添加/修改测量对象：

  3> reconfigure the entry with the value received for this measObject, except for the fields cellsToAddModList, cellsToRemoveList…

  当修改一个已存在的measObject时，规范指出，UE会用新配置替换旧配置，但小区列表（黑/白名单）的修改是增量式的。例如，cellsToAddModList用于向现有的小区列表中添加新成员，而cellsToRemoveList用于删除成员。这种设计避免了每次修改都需要下发完整的长列表，节省了信令开销。

2.2.4 报告配置的增删改查 (5.5.2.6 & 5.5.2.7)

报告配置（ReportConfig）的增删改查逻辑与测量对象类似，也是通过相应的ToRemoveList和ToAddModList完成。当一个reportConfigId被删除时，所有与之关联的measId也会被级联删除。

2.2.5 其他关键测量配置

除了“三驾马车”，measConfig还包含其他重要的全局配置：

• quantityConfig (5.5.2.8)：定义了L3滤波的系数。网络可以为不同的RS类型（SSB vs CSI-RS）、不同的测量量（RSRP vs RSRQ）配置不同的滤波系数，以适应不同的无线环境和移动速度。

• measGapConfig (5.5.2.9)：配置测量间隙。如前文所述，当UE需要测量异频或异系统小区时，网络会配置一段短暂的“静默”时间，让UE可以安全地切换射频进行测量。

• s-MeasureConfig (5.5.2.1)：这是一个服务小区的测量门限。例如，网络可以配置s-MeasureConfig为-110dBm。只有当服务小区的RSRP低于-110dBm时，UE才需要启动对邻区的测量。这是一种有效的节能机制，当UE处于信号很好的小区中心时，可以避免不必要的邻区测量，从而节省电量。

结语：一个灵活、可扩展的感知框架

通过对5.5.1和5.5.2节的深入剖析，阿哲对RRC的测量体系有了系统性的认识。RRC并没有为每一种测量场景都设计一套独立的流程，而是构建了一个高度抽象和解耦的“三驾马车”模型。

这个模型就像一个乐高积木系统：

• 测量对象 (MeasObject) 是不同形状和颜色的“积木块”（物理资源）。

• 报告配置 (ReportConfig) 是不同的“拼搭规则”（触发逻辑）。

• 测量ID (MeasId) 则是将“积木块”和“拼搭规则”结合起来，创造出一个具体“模型”（测量任务）的说明书。

网络通过measConfig这个“零件包”，可以随时对这个乐高模型进行增减和修改，从而动态地调整UE的“侦察”行为。这种设计的优点是无与伦比的：

• 灵活性：可以轻松组合出各种复杂的测量策略。

• 扩展性：未来如果出现新的测量类型或报告事件，只需定义新的MeasObject或ReportConfig类型，而无需改变整个框架。

• 信令效率：通过增量修改的方式，大大降低了配置更新的信令开销。

阿哲现在已经完全理解了网络是如何下达测量指令的。在下一篇文章中，我们将进入5.5节的后半部分，聚焦于UE在收到这些指令后，如何具体执行测量（5.5.3），如何评估触发条件（5.5.4），以及如何最终生成并发送测量报告（5.5.5）。我们将跟随一个测量事件从触发到上报的全生命周期，深入探索RRC测量的“执行”层面。

---

FAQ

Q1：RRC测量中的“三驾马车”模型（Measurement Object, Reporting Configuration, Measurement ID）相比于早期通信系统（如UMTS）的测量机制，其主要优势是什么？

A1：主要优势在于灵活性和可扩展性。早期系统的测量配置通常是紧耦合的，例如一个测量命令会直接指定要测量的频率、触发的门限和报告的内容。而“三驾马 Waren”模型将这三者解耦：

1. 测什么 (Object)：可以独立定义和修改，例如网络只想更新某个频率的小区黑名单，只需修改MeasObject即可，无需触动报告规则。

2. 怎么报 (ReportConfig)：也可以独立定义和修改，例如网络想调整A3事件的门限，只需修改ReportConfig，所有使用该报告配置的测量任务都会自动更新。

3. 任务关联 (MeasId)：通过MeasId将两者关联，使得配置的组合变得极其灵活。这种模块化的设计使得网络可以轻松地重用配置、进行精细化调整，并且在未来引入新的测量对象或报告事件时，无需改变整个框架，极大地增强了协议的扩展性。

Q2：什么是测量间隙（Measurement Gap）？UE在什么情况下需要它？

A2：测量间隙是一个由网络配置的、周期性的时间窗口，在此窗口内，UE会暂停在服务小区上的数据收发，以便将其射频接收机调谐到其他频率进行测量。UE需要测量间隙主要是在测量异频或异系统的小区时，且其射频硬件不支持在不中断服务链路的情况下进行测量。例如，一个单接收机（single receiver）的UE，在测量一个不同频段的5G小区或一个4G小区时，就必须使用测量间隙。RRC通过measGapConfig配置测量间隙的周期（MGRP）和长度（MGL），以在测量需求和对业务的影响之间取得平衡。

Q3：s-MeasureConfig是如何帮助UE省电的？

A3：s-MeasureConfig定义了一个服务小区质量门限（可以是RSRP或RSRQ）。当网络配置了s-MeasureConfig后，UE会遵循一个“懒汉原则”：

• 只要当前服务小区的信号质量好于这个门限，UE就认为自己处于“信号安全区”，不需要启动对任何同频或异频邻区的测量。

• 只有当服务小区的信号质量差于这个门限时，UE才认为自己可能需要寻找新的小区，此时才启动measConfig中配置的各种邻区测量。

这个机制有效地避免了UE在信号很好的小区中心位置进行不必要的、耗电的邻区搜索，从而显著延长了电池续航时间。

Q4：一个measId可以关联多个measObject或多个reportConfig吗？

A4：不可以。一个measId的设计是一对一的链接关系，即一个measId唯一地将**一个measObject与一个reportConfig**关联起来，定义一个明确的测量任务。但是，反过来是允许的：

• 同一个measObject可以被**多个不同的measId**引用，从而与多个不同的reportConfig关联（例如，对同一个频率既配置事件触发，又配置周期性上报）。

• 同一个reportConfig也可以被**多个不同的measId**引用，从而与多个不同的measObject关联（例如，对不同的频率应用相同的事件A3切换策略）。

Q5：如果网络下发了一个RRCReconfiguration消息，同时删除了一个measId，又添加了一个新的measId，UE会如何执行？

A5：UE会严格按照5.5.2节的顺序执行。measConfig内部的各个列表（如ToRemoveList, ToAddModList）也有其处理顺序。UE会先处理所有“删除”操作，再处理所有“添加/修改”操作。具体来说：

1. 处理measIdToRemoveList：UE会先找到并删除所有指定的measId及其相关状态。

2. 处理measObjectToRemoveList / reportConfigToRemoveList：接着处理对象和报告配置的删除，并级联删除所有受影响的measId。

3. 处理measObjectToAddModList / reportConfigToAddModList：然后处理对象和报告配置的添加/修改。

4. 处理measIdToAddModList：最后，处理measId的添加/修改。

这个严格的“先删后增”的顺序，确保了配置的原子性和一致性，避免了在更新过程中出现临时的配置冲突。