51学通信

深度解析 3GPP TS 38.331：第六章 协议数据单元、格式与参数 (Part 4 - 日志测量与广播多播配置)

21分钟阅读

好的，我们继续深入3GPP TS 38.331规范的第六章。在Part 2中，我们探讨了连接态下的一些基础交互消息。现在，我们将进入两个非常重要且贴近实际网络运维和新业务部署的领域：日志测量（Logged MDT） 和 5G广播多播服务（MBS）。

深度解析 3GPP TS 38.331：第六章 协议数据单元、格式与参数 (Part 4 - 日志测量与广播/多播配置)

本文技术原理深度参考了3GPP TS 38.331 V18.5.0 (2025-03) Release 18规范中，关于“6.2.2 Message definitions”章节中涉及LoggedMeasurementConfiguration及MBS（Multicast Broadcast Service）相关消息的核心内容。本文旨在为读者揭示网络如何利用海量终端进行网络优化数据采集（MDT），以及如何为用户配置和提供5G广播多播服务。

场景切换：从“主动交互”到“被动采集”与“群体服务”

我们的主角“小明”依然处于RRC_CONNECTED态。不过，接下来的故事将展现两种全新的通信模式：

  1. 网络性能优化 - MDT (Minimization of Drive Tests): 运营商希望优化一条新建地铁线路的5G覆盖。传统方式是派工程师拿着测试设备（俗称“扫频仪”）反复乘坐地铁进行路测，成本高昂且效率低下。有了MDT，网络可以直接下发一个“后台任务”给像小明这样乘坐地铁的普通用户手机，让手机在空闲或非激活状态下，静默地记录沿途的信号质量、小区切换等信息，并在合适的时机上传。这就是LoggedMeasurementConfiguration消息的用武之地。

  2. 新业务体验 - MBS (Multicast Broadcast Service): 小明来到了一个大型体育场观看比赛。为了给现场数万名观众提供低时延、多角度的精彩回放，如果每个人都通过独立的单播流观看，会瞬间压垮基站。此时，运营商启用了MBS服务，通过一个公共的广播信道，将视频流一次性发送给场内所有订阅该服务的用户。我们将通过MBS相关的三个核心消息，了解小明的手机是如何加入这场“集体狂欢”的。

1. LoggedMeasurementConfiguration (日志测量配置)

The LoggedMeasurementConfiguration message is used to perform logging of measurement results while in RRC_IDLE or RRC_INACTIVE. It is used to transfer the logged measurement configuration for network performance optimisation.

解读与场景：

此消息是网络发起日志式MDT (Logged MDT) 的“任务书”。网络通过该消息，精确地指示UE在进入RRC_IDLE或RRC_INACTIVE状态后，需要记录哪些测量信息、在哪个地理区域记录、记录多久，以及触发记录的条件是什么。这些日志被UE存储在本地，直到网络后续通过UEInformationRequest消息请求上报。

  • 信令承载: SRB1

  • RLC-SAP: AM

  • 逻辑信道: DCCH

  • 方向: Network to UE

1.1 消息结构 (ASN.1)

 
LoggedMeasurementConfiguration-r16 ::= SEQUENCE {
 
    criticalExtensions                  CHOICE {
 
        loggedMeasurementConfiguration-r16    LoggedMeasurementConfiguration-r16-IEs,
 
        criticalExtensionsFuture              SEQUENCE {}
 
    }
 
}
 
LoggedMeasurementConfiguration-r16-IEs ::= SEQUENCE {
 
    traceReference-r16                  TraceReference-r16,
 
    traceRecordingSessionRef-r16        OCTET STRING (SIZE (2)),
 
    tce-Id-r16                          OCTET STRING (SIZE (1)),
 
    absoluteTimeInfo-r16                AbsoluteTimeInfo-r16,
 
    areaConfiguration-r16               AreaConfiguration-r16 OPTIONAL, --Need R
 
    plmn-IdentityList-r16               PLMN-IdentityList2-r16 OPTIONAL, --Need R
 
    bt-NameList-r16                     SetupRelease { BT-NameList-r16 } OPTIONAL, --Need M
 
    wlan-NameList-r16                   SetupRelease { WLAN-NameList-r16 } OPTIONAL, --Need M
 
    sensor-NameList-r16                 SetupRelease { Sensor-NameList-r16 } OPTIONAL, --Need M
 
    loggingDuration-r16                 LoggingDuration-r16,
 
    reportType                          CHOICE {
 
        periodical                          LoggedPeriodicalReportConfig-r16,
 
        eventTriggered                      LoggedEventTriggerConfig-r16,
 
        ...
 
    },
 
    lateNonCriticalExtension            OCTET STRING OPTIONAL,
 
    nonCriticalExtension                LoggedMeasurementConfiguration-v1700-IEs OPTIONAL
 
}
 
-- ... 后续版本扩展

1.2 关键参数与表格解读

这张庞大的消息结构定义了一个完整的MDT任务，我们来拆解其中的核心要素。

LoggedMeasurementConfiguration 字段描述

| 字段名 | 描述 |

|:---|:---|

| absoluteTimeInfo | 指示当前小区的绝对时间。作为后续日志时间戳的基准。 |

| areaConfiguration | 用于限制UE执行测量日志记录的区域。该区域可以是小区列表、跟踪区码/频率列表、PNI-NPN标识或SNPN标识。 |

| earlyMeasIndication | 如果包含，该字段指示UE被允许在日志测量中记录与早期测量相关的频率上的测量。 |

| eventType | outOfCoverage值指示UE在进入任何小区选择状态时执行测量日志记录，eventL1值指示UE在满足事件中配置的触发条件（类似于事件A2）时为驻留小区执行测量日志记录。 |

| plmn-IdentityList | 指示一组PLMN，定义UE何时执行测量日志记录以及相关的状态指示和信息检索。 |

| sigLoggedMeasType | 如果包含，该字段指示一个基于信令的日志测量配置 (参考 TS 37.320)。 |

| tce-Id | 参数“Trace Collection Entity Id”，即跟踪收集实体ID (参考 TS 32.422)。 |

| traceRecordingSessionRef | 参数“Trace Recording Session Reference”，即跟踪记录会话参考 (参考 TS 32.422)。 |

| reportType | 参数配置MDT配置的类型，特别是周期性MDT配置或事件触发MDT配置。 |

  • Trace/TCE相关字段: traceReference-r16, traceRecordingSessionRef-r16, tce-Id-r16 这三个字段是溯源标识。它们将这次MDT任务与运营商后台运维系统（OAM）中的一个具体“工单”关联起来。当小明手机的日志上传后，后台系统可以根据这些ID，准确地知道这份数据是为了“优化地铁线覆盖”这个任务而采集的。

  • areaConfiguration-r16 (区域配置): 这是地理范围限定。运营商不希望所有UE都进行日志记录。通过这个字段，网络可以精确指定一个区域，比如“仅在地铁一号线沿线的这些小区（Cell ID列表）或这个跟踪区（Tracking Area）内才执行日志记录”。小明的手机一旦离开这个区域，就会自动暂停MDT任务。

  • loggingDuration-r16 (记录时长): 时间范围限定。定义了整个MDT任务的有效时间，例如“从现在开始，持续8小时”。

  • reportType (报告类型): 数据采集模式。这是MDT任务的核心逻辑。

    • periodical (周期性): UE会按照loggingInterval-r16定义的固定周期（如每5秒）记录一次测量结果。这种模式数据量大，但信息连续。

    • eventTriggered (事件触发): UE只在特定事件发生时才记录日志。最常见的事件是eventL1，即服务小区的信号质量（如RSRP）低于l1-Threshold定义的阈值。这可以高效地捕捉到网络中的弱覆盖点。outOfCoverage事件则用于记录UE掉网的时刻和位置。

在地铁场景中，网络可能会给小明下发一个事件触发的MDT任务，areaConfiguration覆盖所有地铁站及沿线隧道的小区，eventType设置为eventL1并配置一个-105dBm的RSRP阈值。这样，只有当小明乘坐的列车经过信号不佳的路段时，手机才会记录下弱覆盖点的测量信息，极大地提高了数据采集的针对性。

2. 5G广播/多播服务 (MBS) 消息三件套

现在，小明来到了体育场。这里的gNB正在通过MCCH（Multicast Control Channel）信道，广播MBSBroadcastConfiguration消息，宣告多角度回放服务的存在。

2.1 MBSBroadcastConfiguration (MBS广播配置)

The MBSBroadcastConfiguration message contains the control information applicable for MBS broadcast services transmitted via broadcast MRB.

解读与场景：

这是MBS的“服务公告板”。它由网络在MCCH上广播，告诉区域内的所有UE，当前小区正在提供哪些MBS广播服务，以及接收这些服务所需的技术参数。

  • 信令承载: N/A (通过MCCH广播)

  • RLC-SAP: UM

  • 逻辑信道: MCCH

  • 方向: Network to UE

MBSBroadcastConfiguration 字段描述

| 字段名 | 描述 |

|:---|:---|

| pdsch-ConfigMTCH | 提供用于获取MTCH的PDSCH的参数。当该字段不存在时，UE应使用pdsch-ConfigMCCH中的参数来获取MTCH的PDSCH。 |

| mbs-SessionInfoList | 提供当前小区中由MBS广播提供的每个MBS会话的配置。 |

| mbs-NeighbourCellList | 提供一个或多个通过广播MRB提供MBS广播服务的邻区列表，这些服务也由当前小区提供。 |

  • mbs-SessionInfoList-r17: 列出了当前小区提供的所有MBS广播会话（Session）。每个会话都有唯一的ID（TMGI），以及关联的QoS信息。小明的手机通过解析这个列表，就能知道“高清视角1”、“VR视角2”等服务的存在。

  • pdsch-ConfigMTCH-r17: 提供了解码MBS数据流所需的物理层参数。MTCH（Multicast Traffic Channel）是承载实际MBS用户数据的信道，这份配置告诉UE该如何去监听和解码它。

  • mbs-NeighbourCellList-r17: 这对于移动场景下的MBS接收至关重要。它告诉小明，当他在体育场内走动时，哪些邻近的小区同样在广播这些MBS服务。这样，手机就可以提前准备，在小区切换时无缝地继续接收MBS数据流，保证视频不会中断。

2.2 MBSInterestIndication (MBS兴趣指示)

The MBSInterestIndication message is used to inform network that the UE is receiving/ interested to receive or no longer receiving/ interested to receive MBS broadcast service(s) via a broadcast MRB.

解读与场景：

当小明在手机上点开体育场官方App并选择“多角度回放”功能后，手机需要告诉网络：“我对这个服务感兴趣”。MBSInterestIndication就是UE向网络表达其对MBS服务兴趣的上行消息。

  • 信令承载: SRB1

  • RLC-SAP: AM

  • 逻辑信道: DCCH

  • 方向: UE to Network

MBSInterestIndication 字段描述

| 字段名 | 描述 |

|:---|:---|

| mbs-FreqList | UE正在或有兴趣通过广播MRB接收MBS广播服务的MBS频率列表。 |

| mbs-NonServingInfoList| 指示非服务小区上的MBS广播接收信息。 |

| mbs-Priority | 指示UE是否将MBS广播接收优先于单播和MBS多播接收。 |

| mbs-ServiceList | UE正在或有兴趣接收的MBS广播服务列表。 |

  • mbs-FreqList-r17 和 mbs-ServiceList-r17: 明确上报UE感兴趣的服务ID和所在频率。

  • mbs-Priority-r17: 这是一个非常关键的字段。如果App将回放体验设为最高优先级，手机可能会将此字段设为true。这相当于告诉网络：“为了保证我的MBS视频流畅，我可以接受我的微信消息等单播业务稍微延迟一些”。网络可以利用这个信息进行更智能的无线资源调度和冲突仲裁。

网络收集这些“兴趣指示”有两大好处：1）统计分析，了解MBS服务的受欢迎程度；2）资源优化，例如，如果一个小区内没有任何UE对某个MBS服务感兴趣，网络可能会考虑暂时停播该服务以节省资源。

2.3 MBSMulticastConfiguration (MBS多播配置)

The MBSMulticastConfiguration message contains the control information applicable for MBS multicast services transmitted via multicast MRBs for RRC_INACTIVE UEs.

解读与场景：

此消息与MBSBroadcastConfiguration非常相似，但它专门用于配置多播（Multicast） 服务，特别是针对处于RRC_INACTIVE状态的UE。广播是“大喇叭”，对区域内所有人喊话；多播则是“分组通话”，只发给加入了特定群组的成员。

  • 信令承载: N/A (通过multicast MCCH广播)

  • RLC-SAP: UM

  • 逻辑信道: multicast MCCH

  • 方向: Network to UE

MBSMulticastConfiguration 字段描述

| 字段名 | 描述 |

|:---|:---|

| mbs-NeighbourCellList | 提供一个或多个为RRC_INACTIVE状态的UE提供MBS多播服务的邻区列表。 |

| mbs-SessionInfoListMulticast| 提供当前小区中MBS多播会话的配置。 |

| pdsch-ConfigMTCH | 提供获取多播MTCH的PDSCH的参数。 |

| thresholdMBS-List | 正在RRC_INACTIVE状态下接收多播的UE用于RRC连接恢复的接收质量阈值列表。 |

此消息的大部分参数与广播配置类似，但有一个关键的不同：

  • thresholdMBS-List-r18: 定义了一个接收质量阈值列表（RSRP/RSRQ）。对于一个处于RRC_INACTIVE状态、正在接收多播服务的UE，它会持续监控信号质量。如果信号质量低于这个阈值，UE会主动触发RRC Resume流程，恢复到RRC_CONNECTED态。这背后的逻辑是：信号太差，RRC_INACTIVE下的低功耗接收模式可能不再可靠，需要切换回连接态，让网络通过更鲁棒的专用信道为其服务，或者执行切换，以保证多播业务的连续性。

FAQ环节

Q1：日志式MDT (Logged MDT) 和立即MDT (Immediate MDT) 有什么区别？LoggedMeasurementConfiguration属于哪一种？

A1：两者是MDT的两种主要模式，区别在于数据采集和上报的时间点：

  • 立即MDT (Immediate MDT): UE在RRC_CONNECTED状态下执行测量，并立即通过MeasurementReport消息上报给网络。这通常用于需要实时网络信息的场景，如切换优化。

  • 日志式MDT (Logged MDT): UE在RRC_IDLE或RRC_INACTIVE状态下执行测量，并将结果存储在本地日志中。只有当UE后续返回RRC_CONNECTED状态，并且网络主动请求时，UE才会上报这些日志。LoggedMeasurementConfiguration消息正是用于配置日志式MDT的。日志式MDT的优点是对用户体验影响极小，且能收集到UE在空闲/非激活状态下的网络行为数据。

Q2：UE发送MBSInterestIndication对网络来说是强制性的吗？它对UE自身有什么好处？

A2：从协议角度看，当UE打算接收或停止接收某个MBS广播服务时，它应该发送该指示。这对网络进行用户统计和资源管理至关重要。对UE自身而言，最直接的好处与mbs-Priority字段相关。通过上报高优先级，UE可以影响网络调度器的行为，使其在资源冲突时优先保障MBS业务的QoS，从而获得更流畅的视频体验。此外，在未来更智能的网络中，UE的兴趣指示也可能影响网络对MBS服务的动态启停决策，间接影响UE的可用服务。

Q3：5G MBS的广播（Broadcast）和多播（Multicast）模式有什么核心区别？

A3：核心区别在于服务目标群体和资源效率：

  • 广播: 面向地理区域内的所有UE。数据在空口上是公开传输的，任何UE只要有相应的配置都可以接收。适用于体育场直播、区域灾难告警等大规模公共信息分发场景。

  • 多播: 面向一个特定的UE群组。只有加入了该多播群组的UE才能接收和解码数据。这需要更精细的用户和服务管理。适用于付费视频分发、企业内部视频会议等场景。多播比广播更具目标性，资源利用更精确。MBSMulticastConfiguration特别关注RRC_INACTIVE态UE，也是为了在保证业务连续性的同时，兼顾终端的功耗。

Q4：在LoggedMeasurementConfiguration中，如果areaConfiguration和loggingDuration同时存在，UE的行为是怎样的？

A4：UE会将两者作为“与”逻辑（AND）来执行MDT任务。也就是说，UE必须同时满足两个条件才会进行日志记录：1）UE的当前位置处于areaConfiguration所定义的地理区域内；2) 当前时间在loggingDuration定义的有效时长内。只要有任何一个条件不满足，例如小明走出了指定的区域，或者MDT任务时长已到，手机就会暂停或终止日志记录。

Q5：MBSMulticastConfiguration中的thresholdMBS-List阈值是做什么用的？为什么RRC_INACTIVE态下的多播接收需要这个机制？

A5：这个阈值是RRC_INACTIVE态下MBS业务连续性的**“保险丝”**。在RRC_INACTIVE态，UE以低功耗方式监听寻呼和MBS数据，其移动性管理也相对简化（基于小区重选）。如果信号质量变得很差，这种简化的模式可能不足以维持可靠的多播接收，容易出现视频卡顿或中断。

thresholdMBS-List设定了一个信号质量底线。一旦UE检测到信号低于此底线，它会立即“唤醒”并恢复到RRC_CONNECTED态。回到连接态后，网络拥有了对UE的完全控制权，可以采取更强有力的措施，如执行切换（Handover）到信号更好的小区、或将业务从多播流切换到更可靠的单播流，从而主动保障用户的观看体验不被中断。

关系图谱