51学通信

深度解析 3GPP TS 38.331：5.6 UE capabilities (UE能力交互：网络如何“知人善任”)

21分钟阅读

好的，我们继续跟随工程师阿哲的脚步，深入探索3GPP TS 38.331规范。在完成了对RRC协议核心流程（连接建立、重配置、移动性、测量等）的系统学习后，阿哲的知识体系已经相当完备。但他知道，还有一个至关重要的环节尚未触及——那就是UE如何向网络“亮明身份”和“展示肌肉”。

网络在为UE提供服务时，必须先了解它的“家底”：它支持哪些频段？支持多大的带宽？MIMO能力如何？是否支持双连接？是否支持Sidelink？……所有这些信息，统称为UE能力（UE Capability）。如果网络对UE的能力一无所知，就如同一个大厨不知道食客的口味和过敏史，无法做出最合适的菜肴。

本篇文章，我们将聚焦于规范的5.6节“UE capabilities（UE能力）”，详细拆解网络是如何发起能力查询，以及UE是如何搜集、整理并上报自己庞大而复杂的无线能力信息的。我们将揭示RRC如何扮演“星探”和“经纪人”的角色，确保网络能够“知人善任”，为每个UE提供最优的个性化服务。

深度解析 3GPP TS 38.331：5.6 UE capabilities (UE能力交互：网络如何“知人善任”)

本文技术原理深度参考了3GPP TS 38.331 V18.5.1 (2025-03) Release 18规范中，关于“5.6 UE capability transfer (UE能力传输)”的核心章节，旨在为读者深入剖析UE能力查询与上报的完整信令流程、能力信息的组织结构，以及在复杂网络环境下（如MR-DC）的能力过滤与一致性要求。

1. UE能力的“人口普查”：为何以及何时需要 (解读5.6.1.1 & 5.6.1.2)

5.6.1.1 General

This clause describes how the UE compiles and transfers its UE capability information upon receiving a UECapabilityEnquiry from the network.

Figure 5.6.1.1-1: UE capability transfer 以一个简洁的交互图展示了该流程的核心：网络发送UECapabilityEnquiry（能力查询）请求，UE回复UECapabilityInformation（能力信息）消息。

1.1 为何需要查询UE能力？

UE能力信息是网络进行高级功能配置的前提。没有这些信息，网络无法：

  • 配置载波聚合/双连接：网络不知道UE支持哪些频段组合，无法为其配置SCell或SCG。

  • 启用高阶MIMO：网络不知道UE支持的MIMO层数，只能使用基础配置，无法发挥UE的最大潜力。

  • 分配高级特性：网络不知道UE是否支持Sidelink、IAB、RedCap等新特性，无法为其开启相应的服务。

1.2 何时发起查询？

5.6.1.2 Initiation

The network initiates the procedure to a UE in RRC_CONNECTED when it needs (additional) UE radio access capability information. The network should retrieve UE capabilities only after AS security activation.

网络在RRC_CONNECTED状态下，当需要了解UE能力时，就会发起此流程。关键点在于：

  • 按需发起：通常在RRC连接建立后、准备为UE配置高级功能（如CA/DC）之前发起。

  • 安全保障：规范强烈建议在AS安全激活之后才进行能力查询。因为UE能力信息可能非常庞大，且涉及设备的关键特性，在加密信道上传输可以防止被窃听和分析，保护了用户隐私和网络安全。

  • 核心网需求：能力查询不仅可以由gNB发起，也可能由核心网（AMF）通过NAS信令触发。例如，AMF想知道UE是否支持某种切片服务，就会请求gNB去获取UE的相关能力。

2. “按需填表”：网络的能力查询 (解读5.6.1.3 Reception of the UECapabilityEnquiry)

网络并非总是要求UE上报其全部能力。一个全功能UE的能力信息可能非常庞大，完整上报会占用大量空口资源。因此，UECapabilityEnquiry消息中包含了一个强大的**过滤器（Filter）**机制，允许网络精确地“点菜”。

1> if the ue-CapabilityRAT-RequestList contains a UE-CapabilityRAT-Request with rat-Type set to nr:

2> include in the ue-CapabilityRAT-ContainerList a UE-CapabilityRAT-Container of the type UE-NR-Capability and with the rat-Type set to nr;

2> include the supportedBandCombinationList, featureSets and featureSetCombinations as specified in clause 5.6.1.4;

UECapabilityEnquiry消息通过ue-CapabilityRAT-RequestList来指定它感兴趣的无线技术类型（RAT-Type）。

场景模拟: 阿哲的手机支持5G NR和4G E-UTRA，并且支持EN-DC双连接。gNB现在想为他配置EN-DC，因此需要同时了解他的NR能力和MR-DC（多RAT双连接）能力。gNB会发送一个包含以下请求的UECapabilityEnquiry：

  1. 一个rat-Type为nr的请求，并可能附带一个frequencyBandListFilter，只询问UE在N41和N78频段上的能力。

  2. 一个rat-Type为eutra-nr的请求，询问UE支持的EN-DC频段组合能力。

2.1 能力分层与容器化

UE的能力信息被组织成一个树状的、模块化的结构。每个RAT的能力都封装在一个独立的“容器”（UE-CapabilityRAT-Container）中。

  • UE-NR-Capability: 包含纯NR相关的所有能力，如支持的NR频段、NR特性集等。

  • UE-EUTRA-Capability: 包含纯E-UTRA相关的所有能力。

  • UE-MRDC-Capability: 包含所有多RAT双连接相关的能力，如支持的EN-DC、NE-DC频段组合。

这种容器化的设计使得能力信息的组织非常清晰，并且便于扩展。

3. “整理家底”：UE的能力信息编译 (解读5.6.1.4 Setting band combinations, feature set combinations and feature sets)

收到UECapabilityEnquiry后，UE开始了其内部最复杂的信息整理工作之一——编译UECapabilityInformation消息。这个过程的核心是遵循网络提供的过滤器，从自己庞大的能力库中筛选出符合要求的部分，并以一种高度结构化的方式进行组织。

这个结构的核心是三层体系：频段组合（Band Combination）→ 特性集组合（Feature Set Combination）→ 特性集（Feature Set）。

3.1 核心三层结构

阿哲将这个结构比作“买电脑”：

  • BandCombination (频段组合)：就像是电脑的“基本硬件配置”，例如“CPU是Intel i7，显卡是NVIDIA RTX 4080”。在UE能力中，一个频段组合定义了UE可以同时工作的多个载波，例如bandCombination: {n41(PCell) + n78(SCell)}。

  • FeatureSetCombination (特性集组合)：定义了在上述硬件配置下，每个组件（频段）可以开启的“软件功能等级”。例如，“CPU可以开启睿频，显卡可以开启光线追踪”。在UE能力中，一个特性集组合会将一个BandCombination中的每个频段，映射到一个FeatureSet上。

  • FeatureSet (特性集)：这是最底层的能力单元，定义了一个频段上所支持的具体物理层、MAC层等特性。例如，“支持256QAM调制”、“支持4x4 MIMO”、“支持X个HARQ进程”等。

3.2 编译过程

The UE invokes the procedures in this clause if the NR or E-UTRA network requests UE capabilities for nr, eutra-nr or eutra…

1> compile a list of “candidate band combinations” according to the filter criteria in capabilityRequestFilterCommon (if included), only consisting of bands included in frequencyBandListFilter…

UE的编译过程大致如下：

  1. 过滤频段组合：UE首先根据网络在查询中提供的frequencyBandListFilter，从自己支持的所有BandCombination中，筛选出完全包含在Filter范围内的“候选频段组合”。

  2. 打包信息：对于每一个入选的频段组合，UE会将其对应的FeatureSetCombination和被引用的所有FeatureSet都打包进UECapabilityInformation消息中。

  3. 保证一致性：

    NOTE 2: …the IDs used in the featureSets must match the IDs referred to in featureSetCombinations across all three containers.

    规范特别强调了ID的一致性。在MR-DC场景下，UE-MRDC-Capability中的特性集组合会引用UE-NR-Capability和UE-EUTRA-Capability中定义的特性集。这三份“能力报告”中，所有ID必须能够相互匹配，构成一个逻辑上完整的整体。

3.3 消息过大怎么办？——RRC消息分段

1> if the RRC message segmentation is enabled based on the field rrc-SegAllowed received, and the encoded RRC message is larger than the maximum supported size of a PDCP SDU specified in TS 38.323:

2> initiate the UL message segment transfer procedure as specified in clause 5.7.7;

UE的能力信息可能非常庞大，一个UECapabilityInformation消息编码后可能会超过PDCP SDU的最大尺寸（通常是9000字节）。此时，如果网络在查询时允许分段（rrc-SegAllowed），UE会自动启动5.7.7节定义的UL消息分段流程。它会将这条巨大的消息分割成多个小的ULDedicatedMessageSegment消息，逐个发送给网络。网络在收到所有分片后，再将其拼接成完整的UECapabilityInformation消息。

这个机制保证了即使是能力最复杂的UE，也能够可靠地将其完整的“简历”递交给网络。

4. RRC的“杂项”：其他信息传输流程 (解读5.7 Other)

在完成了对UE能力这一大块头的解读后，阿哲快速浏览了5.7节的其他流程。这些流程虽然不像连接控制或移动性那样核心，但在特定场景下也扮演着重要的角色。

4.1 DL/UL Information Transfer (5.7.1 & 5.7.2)

  • DL Information Transfer: 用于网络向UE下发专用的NAS消息。与RRCSetupComplete中捎带NAS消息不同，这个流程允许网络在RRC_CONNECTED状态下的任何时候主动向UE推送NAS信令。

  • UL Information Transfer: 相应的，UE也可以在RRC_CONNECTED状态下，通过此流程主动向网络发送NAS消息。

这两个流程为AS层和NAS层之间提供了一条灵活的、按需的专用信令通道。

4.2 失败信息上报 (5.7.3 SCG failure information & 5.7.5 Failure information)

  • SCG Failure Information: 我们在双连接章节已经提到，当SCG侧发生故障（如RLF、配置失败）时，UE会通过此流程，使用SRB1向主节点MN报告SCG的失败情况。

  • Failure Information: 这是一个更通用的失败报告流程，例如，当某个DRB的RLC层达到最大重传次数时，UE可以通过此流程向网络报告RLC失败，帮助网络快速定位问题。

4.3 UE辅助信息 (5.7.4 UE Assistance Information)

我们在otherConfig的解读中已经接触过这个流程。它是UE向网络主动上报自身状态和偏好（如过热、DRX偏好等）的统一出口。网络通过RRCReconfiguration中的otherConfig为UE“打开”上报的开关，而UE则通过UEAssistanceInformation消息来“表达”自己的诉求。

结语：知己知彼，百战不殆

通过对5.6节和5.7节的深入学习，阿哲对RRC协议的“辅助”和“交互”功能有了全面的认识。

  • UE能力交互（5.6节） 体现了“知己知彼”的军事思想。网络通过精确的能力查询，全面掌握了UE的“兵种特性”和“武器装备”，从而能够为其制定最优的“作战计划”（RRC配置），最大限度地发挥其战斗力。RRC的“三驾马车”+ 容器化 + 分段机制，共同构建了一个既灵活又鲁棒的能力上报框架。

  • 其他信息传输流程（5.7节） 则为UE和网络之间，以及不同协议层之间，提供了多样化的信息交换渠道。无论是NAS信令的按需传输，还是各类失败信息的及时上报，亦或是UE偏好的主动表达，都使得UE与网络的交互更加智能、高效和透明。

至此，我们已经基本完成了对RRC协议核心流程（第五章）的全面探索。阿哲的“RRC宪法”研读之旅也取得了阶段性的重大胜利。在接下来的文章中，我们将进入规范的第六章，深入ASN.1的世界，亲眼看看RRC的“圣旨”——那些我们在流程中反复提及的RRC消息，究竟是如何被一笔一划、精确无误地定义出来的。

FAQ

Q1：网络为什么不一次性获取UE的所有能力，而要按需查询？

A1：主要有两个原因：效率和上下文相关性。

  1. 效率：一个全功能5G UE支持的能力组合是海量的，将其全部上报会产生一个极其巨大的UECapabilityInformation消息，严重占用宝贵的上行信令资源，并增加UE和网络的处理负担。

  2. 上下文相关性：网络对UE能力的需求通常是与特定场景相关的。例如，在室内的单频段覆盖场景，网络只关心UE在该频段下的能力，没有必要去查询它在毫米波或其他频段上的能力。按需查询（特别是带有频段过滤器）可以让网络只获取当前所需的最少信息，实现“精准施策”。

Q2：UE能力中的FeatureSet和FeatureSetCombination有什么区别？

A2：可以理解为“单项能力”和“能力组合套餐”的区别。

  • FeatureSet 定义了在一个**单一载波（Component Carrier）**上所支持的一系列特性。它分为下行特性集和上行特性集。例如，一个下行FeatureSet会定义该载波支持的最大MIMO层数、调制方式、带宽等。

  • FeatureSetCombination 则定义了在一个**频段组合（Band Combination）**中，多个载波的FeatureSet是如何组合在一起的。例如，对于一个n41+n78的CA组合，FeatureSetCombination会指定n41载波使用哪个FeatureSet，n78载波使用哪个FeatureSet。它描述的是UE在多载波同时工作时的综合能力。

Q3：如果UE上报的能力与其实际硬件能力不符（例如，为了省电而“谎报”了较低的能力），会发生什么？

A3：这是一个被称为“能力不匹配”（Capability Mismatch）的问题。

  • 低报能力：如果UE上报了比其实际能力更低的能力，网络会信以为真，并只根据其上报的能力进行配置。例如，一个支持4x4 MIMO的手机如果只上报了2x2 MIMO，网络就只会为其配置2x2 MIMO的传输模式，导致UE的峰值速率无法达到最大。在某些情况下，UE可能会为了省电而故意这样做，这被称为UE Assistance Information的一部分。

  • 高报能力：这是一个更严重的问题。如果UE上报了它硬件上不支持的能力（例如，上报了支持某个频段组合，但实际上并不支持），当网络根据这个“虚假”能力下发配置时，UE将无法执行，最终会导致RRC重配置失败，甚至可能触发连接重建或掉线。因此，UE必须准确地上报其能力。

Q4：为什么规范建议在AS安全激活后才进行能力查询？

A4：主要是出于安全和隐私的考虑。UE的能力信息虽然不包含用户个人数据，但它详细揭示了设备的硬件型号、支持的特性和潜在的性能，属于设备的“指纹信息”。如果在非加密的信道（SRB0或安全激活前的SRB1）上传输，这些信息可能会被第三方嗅探和分析，用于用户画像、设备追踪，甚至发现潜在的漏洞。在AS安全激活后，所有RRC信令都经过了加密和完整性保护，可以确保UE能力这一敏感信息在传输过程中的机密性和安全性。

Q5：SCGFailureInformation和FailureInformation有什么区别？

A5：它们都用于上报失败信息，但应用场景和传输路径不同。

  • SCGFailureInformation：专用于双连接（DC）场景。当辅小区组（SCG）发生故障时，UE使用此消息，通过主小区组（MCG）的SRB1（或E-UTRA的SRB1/2）向主节点（MN）报告。MN是SCG的控制者，因此失败信息必须报给MN。

  • FailureInformation：是一个更通用的失败报告机制，目前主要用于报告RLC层面的失败（如达到最大重传次数）或DAPS切换失败。它不限于DC场景。如果失败发生在MCG的承载上，通过SRB1上报；如果发生在SCG的承载上（且SRB3可用），则通过SRB3上报。它的粒度更细，针对的是单个承载的失败，而不是整个小区组的失败。

关系图谱