51学通信

深度解析 3GPP TS 38.331：第六章 协议数据单元、格式与参数 (Part 8 - UE能力查询、信息请求与响应)

18分钟阅读

好的，我们继续深入3GPP TS 38.331规范的第六章。在前几部分，我们已经将RRC连接从建立、重配、移动到释放的整个生命周期串联了起来。现在，我们将目光投向UE与网络之间更为高级和专用的信息交互，这些交互服务于网络诊断、能力协商和特定信息检索。

深度解析 3GPP TS 38.331：第六章 协议数据单元、格式与参数 (Part 8 - UE能力查询、信息请求与响应)

本文技术原理深度参考了3GPP TS 38.331 V18.5.0 (2025-03) Release 18规范中，关于“6.2.2 Message definitions”章节中涉及UECapabilityEnquiry, UECapabilityInformation, UEInformationRequest, UEInformationResponse等核心消息的内容。本文旨在为读者揭示网络如何按需“盘点”UE的真实能力，以及如何“按图索骥”地从UE获取各类存储的报告和信息，从而实现更精细化的网络管理和故障排查。

新的交互模式：网络主动发起的“问卷调查”

至今为止，我们看到的许多信令流程都是由UE的需求（如发起连接、上报测量）或网络的强制指令（如切换、释放）驱动的。而本章我们将聚焦于一种新的交互模式：网络作为“调查员”，主动向UE发起“问卷调查”，以获取其内部信息。我们的主角“小明”的手机，将扮演“受访者”的角色，根据网络的需求，提供精准的“答卷”。

场景设定：

  1. 能力盘点：运营商计划引入一项新的网络切片功能，但需要知道现网中有多少用户的手机支持这项功能。网络将向小明的手机发起一次UECapabilityEnquiry，询问其是否支持特定的切片能力。

  2. 故障回溯：小明昨天向运营商投诉，说他在市中心广场附近时常掉线。为了定位问题，网络工程师需要获取小明手机当时存储的无线链路失败（RLF）报告。网络将向小明的手机发起一次UEInformationRequest，精准索取这份报告。

1. UE能力协商 (UE Capability Enquiry & Information)

这是网络了解UE“能做什么”和“不能做什么”的核心机制。5G终端的能力集极其庞大和复杂，涵盖了支持的频段组合、MIMO层数、调制阶数、各种协议特性（如双连接、载波聚合、网络切片）等成千上万个参数。网络不可能让每个UE在连接建立时都上报完整的“能力简历”，这会造成巨大的信令风暴。因此，采用了按需查询的模式。

1.1 UECapabilityEnquiry (UE能力查询)

The UECapabilityEnquiry message is used to request UE radio access capabilities for NR as well as for other RATs.

  • 方向: Network to UE

  • 逻辑信道: DCCH (SRB1)

解读：这是网络向UE发出的“能力调查问卷”。网络可以通过这个消息，精确地询问UE关于特定RAT（如NR、EUTRA）的特定能力。

UECapabilityEnquiry-IEs 字段描述

| 字段名 | 描述 |

|:---|:---|

| ue-CapabilityRAT-RequestList | 一个列表，每一项都请求特定RAT的能力。 |

| capabilityRequestFilterCommon | 一个通用的能力请求过滤器。网络可以用它来请求满足特定频段组合的能力。这可以大大减少UE上报的能力信息的大小。 |

| rrc-SegAllowed-r16 / rrc-MaxCapaSegAllowed-r17 | 用于控制上行UECapabilityInformation消息的分片。如果网络预计UE的能力信息会非常大，可以通过这些字段启用分片传输，并指定最大分片数量。 |

场景解读：在网络切片部署的场景中，网络会发送一条UECapabilityEnquiry，其中capabilityRequestFilterCommon可能会包含与该新切片功能相关的FeatureSet ID。这相当于在问卷上勾选了问题：“请问你是否支持ID为XXX的这组功能？”

1.2 UECapabilityInformation (UE能力信息)

The IE UECapabilityInformation message is used to transfer UE radio access capabilities requested by the network.

  • 方向: UE to Network

  • 逻辑信道: DCCH (SRB1)

解读：这是UE提交的“能力答卷”。UE会根据UECapabilityEnquiry中的请求，从自身庞大的能力库中筛选出被请求的部分，并封装在这条消息中上报给网络。

UECapabilityInformation-IEs 字段描述

| 字段名 | 描述 |

|:---|:---|

| ue-CapabilityRAT-ContainerList | 包含UE针对请求的各个RAT的能力信息容器。每个容器都是一个透明的字符串，其内容由对应RAT的规范定义。 |

网络收到UECapabilityInformation后，就会更新该UE的上下文，记录下其支持的能力。这些信息是后续所有高级功能配置（如配置双连接、切片、高阶MIMO等）的前提和依据。如果网络给一个不支持某功能的UE下发了相关配置，会导致RRC重配失败。

2. UE信息检索 (UE Information Request & Response)

与能力查询不同，信息检索机制用于获取UE在运行过程中存储的动态信息和历史报告。这些信息对于网络诊断、性能优化和故障回溯至关重要。

2.1 UEInformationRequest (UE信息请求)

The UEInformationRequest message is used by the network to retrieve information from the UE.

  • 方向: Network to UE

  • 逻辑信道: DCCH (SRB1)

解读：这是网络向UE发出的“信息调取函”。网络可以像点菜一样，精确地请求一种或多种UE存储的信息。

UEInformationRequest-IEs 字段描述

| 字段名 | 描述 |

|:---|:---|

| idleModeMeasurementReq-r16 | 请求UE上报其在空闲/非激活状态下存储的测量报告。 |

| logMeasReportReq-r16 | 请求UE上报其存储的日志式MDT (Logged MDT) 报告。 |

| connEstFailReportReq-r16 | 请求UE上报其存储的连接建立失败报告。 |

| ra-ReportReq-r16 | 请求UE上报其存储的随机接入过程报告。 |

| rlf-ReportReq-r16 | 请求UE上报其存储的无线链路失败（RLF）报告。 |

| mobilityHistoryReportReq-r16 | 请求UE上报其移动性历史报告。 |

| successHO-ReportReq-r17 | 请求UE上报关于成功切换的报告。 |

| flightPathInfoReq-r18 | 请求UE上报其飞行路径信息（针对无人机等）。 |

场景解读：在小明投诉掉线的场景中，网络工程师会通过OAM系统触发，让gNB向小明的手机发送一条UEInformationRequest，其中rlf-ReportReq-r16字段被设置为true。

2.2 UEInformationResponse (UE信息响应)

The UEInformationResponse message is used by the UE to transfer information requested by the network.

  • 方向: UE to Network

  • 逻辑信道: DCCH (SRB1 或 SRB2)

解读：这是UE提交的“信息档案”。UE会根据UEInformationRequest中的请求，打包相应的信息并上报。

UEInformationResponse-IEs 字段描述

| 字段名 | 描述 |

|:---|:---|

| measResultIdleEUTRA-r16 / measResultIdleNR-r16 | 空闲/非激活态下的E-UTRA/NR测量结果。 |

| logMeasReport-r16 | 日志式MDT报告。 |

| connEstFailReport-r16 | 连接建立失败报告。 |

| ra-ReportList-r16 | 随机接入报告列表。 |

| rlf-Report-r16 | 无线链路失败报告。 |

| mobilityHistoryReport-r16 | 移动性历史报告。 |

| successHO-Report-r17 | 成功切换报告。 |

| flightPathInfoReport-r18 | 飞行路径信息报告。 |

rlf-Report-r16 深度解析

这是网络排障的“黑匣子”，它详细记录了UE在发生RLF时的“最后一刻”。其核心内容包括：

  • measResultLastServCell-r16: 失败前，服务小区的最后一次测量结果。

  • measResultNeighCells-r16: 失败前，邻区的最后一次测量结果。这对于分析是否是覆盖空洞或切换迟缓问题至关重要。

  • previousPCellId-r16: 如果RLF发生在切换后不久，这里会记录切换前的源小区ID。

  • failedPCellId-r16: 发生RLF的小区ID。

  • connectionFailureType-r16: 失败类型，rlf（无线链路失败）或hof（切换失败）。

  • rlf-Cause-r16: RLF的具体原因，如t310-Expiry（失步）、randomAccessProblem等。

场景解读：小明的手机收到请求后，会找到本地存储的、与市中心广场相关的rlf-Report，将其封装在UEInformationResponse消息中发送给网络。工程师通过分析这份报告发现，在RLF发生时，服务小区的RSRP已经极低，但UE测量到的一个邻区信号却很强。这表明，问题可能出在切换参数配置不合理，导致UE切换过迟。工程师据此调整了相关小区的切换门限，问题得以解决。

3. ULInformationTransfer (上行信息传输) & 其变体

这个消息族是下行DLInformationTransfer的对应物，用于UE向网络透明地传输非RRC信令。

3.1 ULInformationTransfer

The ULInformationTransfer message is used for the uplink transfer of NAS or non-3GPP dedicated information, or IAB-DU specific F1-C related information.

  • 方向: UE to Network

  • 逻辑信道: DCCH (SRB2 或 SRB1)

解读：与下行类似，这是RRC层为上层（主要是NAS）提供的“上行邮递服务”。

场景：小明在手机上购买了一个新的流量包。这个操作需要UE的NAS层向核心网（AMF）发送一条PDU Session Modification Request消息。NAS层会将这条消息递交给RRC层，RRC层会将其封装在ULInformationTransfer的dedicatedNAS-Message字段中，发送给gNB。gNB再将其透传给AMF。

3.2 ULInformationTransferIRAT

The ULInformationTransferIRAT message is used for the uplink transfer of information terminated at NR MCG but specified by another RAT.

  • 方向: UE to Network (SRB1)

解读：用于在NR链路上，传输发往NR MCG、但内容格式由另一个RAT（如E-UTRA）定义的消息。一个典型的应用是V2X sidelink通信，UE可以通过NR Uu链路，向网络上报在LTE PC5链路上收到的V2X消息。

3.3 ULInformationTransferMRDC

The ULInformationTransferMRDC message is used for the uplink transfer of MR-DC dedicated information…

  • 方向: UE to Network (SRB1 或 SRB3)

解读：这是双连接（MR-DC）场景下的特殊上行传输通道。当UE需要向SN（辅节点）发送一条消息（如SCGFailureInformation、SN侧的MeasurementReport）时，这条消息会被封装在ULInformationTransferMRDC中，通过MCG链路（SRB1）发送给MN（主节点），再由MN通过Xn接口转发给SN。反之亦然。它扮演了跨节点传输RRC消息的“内部信使”角色。

FAQ环节

Q1：网络为什么不让UE在RRC连接建立时就上报所有能力，而要采用“查询-响应”的方式？

A1：主要原因是为了节省信令开销和降低连接建立时延。5G UE的能力集非常庞大，如果每次连接都全量上报，会产生巨大的信令消息，不仅占用宝贵的无线资源，还会显著增加RRC连接建立的时间。采用“查询-响应”的按需模式，网络只在需要配置特定功能（如双连接、切片）或怀疑UE能力发生变化时，才发起查询。此外，网络还可以使用过滤器（capabilityRequestFilterCommon）只查询其感兴趣的能力子集，进一步减少了上报信息量。

Q2：UE存储的这些报告（如RLF报告、连接失败报告）会一直保留吗？什么时候会被删除？

A2：不会一直保留。UE存储这些报告的空间是有限的。规范定义了相关的存储和管理规则：

  • 存储：UE在检测到相关事件（如RLF）时，会生成并存储一份报告。

  • 上报：当UE重新连接到网络，并且网络通过UEInformationRequest请求该报告时，UE会将其上报。

  • 删除：一旦UE成功将报告上报给网络，它通常就会删除这份报告，以释放存储空间。此外，如果UE在存储报告后，长时间没有机会连接到网络或网络一直没有请求，这些过时的报告也可能会被UE自行删除。

Q3：UEInformationRequest和UECapabilityEnquiry都是网络向UE请求信息，它们之间有什么本质区别？

A3：本质区别在于请求的信息的性质和来源：

  • UECapabilityEnquiry: 请求的是UE的静态能力信息。这些信息是UE出厂时就固化在硬件和软件中的，描述了“UE能做什么”。这些信息通常是固定不变的（除非UE进行软件升级）。

  • UEInformationRequest: 请求的是UE在网络运行过程中记录的动态事件和历史信息。这些信息是UE在与网络交互时产生的，描述了“UE经历了什么”，如失败事件、移动历史等。这些信息是动态变化的。

简单比喻，UECapabilityEnquiry是在查UE的“产品规格说明书”，而UEInformationRequest是在调取UE的“行车记录仪”或“黑匣子”数据。

Q4：上行消息分片（通过 ULDedicatedMessageSegment）通常在什么场景下会用到？

A4：上行消息分片主要用于传输两条可能变得非常大的消息：

  1. UECapabilityInformation: 当网络没有使用过滤器，或者请求了非常复杂的能力组合（如大量的EUTRA-NR频段组合）时，UE的能力报告会变得非常庞大，可能超出PDCP SDU的大小限制，此时就需要分片。

  2. MeasurementReportAppLayer: 如果UE配置了上报非常详细的应用层测量，或者同时上报多个应用的测量，这条消息也可能变得很大。

网络通过在UECapabilityEnquiry消息中设置rrc-SegAllowed-r16来使能UE上行消息分片功能。

Q5：ULInformationTransferMRDC这个消息的存在，是否意味着MN（主节点）需要解析发往SN（辅节点）的RRC消息？

A5：不需要。与异RAT切换的容器消息类似，ULInformationTransferMRDC在这里也扮演着“透明管道”的角色。当UE要向SN发送一条SCGFailureInformation时，UE的RRC层会生成完整的SCGFailureInformation消息，然后将其作为OCTET STRING封装进ULInformationTransferMRDC的ul-DCCH-MessageNR字段。MN收到后，只需识别出这是发往SN的MRDC消息，然后通过Xn接口将ul-DCCH-MessageNR字段中的内容原封不动地转发给SN即可，MN本身不解析其内容。

关系图谱