51学通信

深度解析 3GPP TS 38.331：第六章 协议数据单元、格式与参数 (Part 9 - 安全模式、系统信息请求与总结)

18分钟阅读

好的，我们已经来到了3GPP TS 38.331规范第六章深度解读系列的最后一篇。在前几部分，我们已经系统地梳理了UE生命周期中的绝大多数RRC消息。本篇我们将完成“收尾”工作，探讨一些在特定场景下至关重要、用于保障安全和同步性的消息，并对第六章的整体逻辑进行一个全面的总结。

深度解析 3GPP TS 38.331：第六章 协议数据单元、格式与参数 (Part 9 - 安全模式、系统信息请求与总结)

本文技术原理深度参考了3GPP TS 38.331 V18.5.0 (2025-03) Release 18规范中，关于“6.2.2 Message definitions”章节中涉及SecurityModeCommand, SecurityModeComplete, SecurityModeFailure, RRCSystemInfoRequest等核心消息的内容。本文旨在为读者揭示5G空口安全如何通过RRC信令激活，以及UE在IDLE/INACTIVE状态下如何高效获取最新的系统信息。

最后的场景：安全加固与信息同步

我们的主角“小明”的手机在与5G网络完成RRC连接建立后，并非立即就可以传输加密的用户数据。双方需要进行一次“安全握手”，以激活空口的加密和完整性保护。此外，当小明的手机在RRC_IDLE或RRC_INACTIVE状态下驻留在一个小区很长时间后，它如何确保自己本地缓存的系统信息（SIBs）仍然是最新、最有效的呢？本章的两个主角消息将为我们解答这些问题。

  1. 场景一：建立安全通道。小明的手机刚刚完成了RRCSetupComplete的发送。此时，RRC信令（SRB1）已经建立，但还没有进行完整性保护，更没有加密。网络将立即发起安全模式控制流程，为后续所有信令和数据的传输“加锁”。

  2. 场景二：信息更新确认。小明在一个商场里待了几个小时，手机一直处于RRC_IDLE状态。在他准备离开商场时，手机需要确认一下当前小区的系统信息是否有变动（比如，网络是否新增了一个载波频率）。RRCSystemInfoRequest将帮助手机高效地完成这次“信息同步”。

1. 安全模式控制流程 (Security Mode Control)

这是在RRC连接建立后，激活空口AS（接入层）安全的关键流程。它确保了UE与gNB之间的信令具有完整性保护（防止被篡改），用户数据具有加密（防止被窃听）。

1.1 SecurityModeCommand (安全模式指令)

The SecurityModeCommand message is used to command the activation of AS security.

  • 方向: Network to UE

  • 逻辑信道: DCCH (SRB1)

解读：这是网络发出的“上锁”指令。gNB在收到RRCSetupComplete（其中搭载了初始NAS消息）并与核心网AMF完成安全上下文协商后，会立即向UE发送此消息。

SecurityModeCommand-IEs 字段描述

| 字段名 | 描述 |

|:---|:---|

| securityConfigSMC | 包含securityAlgorithmConfig，用于配置UE启用哪些加密和完整性保护算法。 |

  • securityAlgorithmConfig: 这是消息的核心。它明确指定了：

    • cipheringAlgorithm: 用于用户面（DRBs）和控制面（SRB2, SRB3）数据加密的算法，如nea0（不加密）、nea1（128-bit SNOW 3G）、nea2（128-bit AES）、nea3（128-bit ZUC）。

    • integrityProtAlgorithm: 用于控制面（SRBs）信令完整性保护的算法，如nia0（不保护）、nia1、nia2、nia3。

UE收到此消息后，会使用从NAS层获取的密钥（K_gNB）和消息中指定的算法，派生出用于加密和完整性保护的所有子密钥，并配置底层的PDCP实体，准备启用安全。

1.2 SecurityModeComplete (安全模式完成)

The SecurityModeComplete message is used to confirm the successful completion of a security mode command.

  • 方向: UE to Network

  • 逻辑信道: DCCH (SRB1)

解读：这是UE的“锁已上好”确认。UE在成功配置好安全算法和密钥后，会发送此消息给gNB。特别重要的是，SecurityModeComplete是第一条由UE发送的、经过完整性保护的上行RRC消息。gNB在接收此消息时，会进行完整性校验。如果校验通过，说明双方的安全上下文完全一致，安全激活成功。

1.3 SecurityModeFailure (安全模式失败)

The SecurityModeFailure message is used to indicate an unsuccessful completion of a security mode command.

  • 方向: UE to Network

  • 逻辑信道: DCCH (SRB1)

解读：如果在SecurityModeCommand处理过程中出现问题（例如，UE不支持网络指定的算法），UE会发送此失败消息。网络收到后，通常会立即释放该RRC连接。

2. 系统信息请求 (System Information Request)

当UE处于RRC_IDLE或RRC_INACTIVE状态时，为了省电，它不会持续监听广播信道来获取所有SIB。它只会在需要时（如发起连接、响应寻呼、或本地缓存的SIB即将过期）去获取。RRCSystemInfoRequest是UE在这些状态下，通过随机接入过程（RACH）向网络请求广播系统信息的一种方式。

2.1 RRCSystemInfoRequest (RRC系统信息请求)

The RRCSystemInfoRequest message is used to request SI message(s) required by the UE as specified in clause 5.2.2.3.3 and 5.2.2.3.3a.

  • 方向: UE to Network

  • 逻辑信道: CCCH (通过Msg3)

解读：这是空闲/非激活态UE发出的“请广播一下最新的系统信息”的请求。它通常发生在UE没有有效的SIB1，或者需要“按需SIB”时。

RRCSystemInfoRequest-IEs 字段描述

| 字段名 | 描述 |

|:---|:---|

| requested-SI-List | 包含一个位图（bit string），用于指示UE请求哪些SI消息。位图中的每一位对应SIB1中schedulingInfoList里SI消息列表的一个条目。 |

| requestedPosSI-List | 与requested-SI-List类似，但用于请求定位相关的posSI消息。 |

场景解读：小明的手机在商场驻留了很久，其本地缓存的系统信息即将过期。此时，手机会发起一次随机接入，在Msg3中携带RRCSystemInfoRequest消息。

  • 如果它只需要更新所有广播的SIB，它可能会在requested-SI-List中将所有对应的bit都设置为’1’。

  • 如果它只是想确认信息是否变化，它可能只请求SIB1。

  • 如果它需要特定的按需SIB（例如，商场内的定位服务），它会精确地在requested-SI-List或requestedPosSI-List中将对应SIB的bit设置为’1’。

网络收到这个请求后，有两种响应方式：

  1. 对于广播SIB：网络会在DL-SCH上调度相应的SI消息广播，并通过PDCCH上的SI-RNTI来通知所有UE。

  2. 对于按需SIB：如果请求者众多，网络可能会临时广播该SIB；如果请求者很少，网络可能会通过寻呼（Paging）将请求的UE拉入连接态，再通过RRCReconfiguration专送给它。

这个机制确保了UE可以高效、低功耗地保持其系统信息的时效性，是空闲/非激活态移动性管理和接入控制的基础。

3. 第六章全面总结与逻辑梳理

至此，我们已经完成了对TS 38.331第六章大部分关键消息的深度解读。现在，让我们跳出单个消息的细节，从更高的视角来梳理本章的内在逻辑和结构。

第六章是RRC协议的“实体层”，它定义了所有“信息积木”。这些“积木”（RRC消息）按照其功能和生命周期，可以被分为几大类：

  1. 系统信息族 (广播): MIB, SIB1…SIBn

    • 使命: 奠定基础。为所有UE提供小区准入、接入控制、邻区信息等最基本的生存环境参数。

    • 交互模式: 网络单向广播。

  2. 连接控制族 (建/释/改): RRCSetupRequest, RRCSetup, RRCSetupComplete, RRCRelease, RRCReconfiguration, RRCReconfigurationComplete, RRCReject

    • 使命: 管理RRC连接的完整生命周期。是整个RRC协议的主干。

    • 交互模式: 严格的请求-响应-确认三步握手。

  3. 连接恢复族 (重建/恢复): RRCReestablishmentRequest, RRCReestablishment, RRCReestablishmentComplete, RRCResumeRequest, RRCResume, RRCResumeComplete

    • 使命: 快速恢复。在连接中断或从低功耗状态返回时，提供比完整连接建立更快的路径，保障业务连续性和低时延。

    • 交互模式: 同样是三步握手，但携带的信息和目标各有侧重。

  4. 移动性与测量族 (上报): MeasurementReport

    • 使命: 提供决策依据。UE作为网络的“传感器”，持续上报无线环境的测量结果，驱动切换等移动性管理。

    • 交互模式: 网络配置 → UE触发 → UE上报。

  5. 安全控制族 (握手): SecurityModeCommand, SecurityModeComplete, SecurityModeFailure

    • 使命: 建立安全通道。激活空口的加密和完整性保护，是所有保密通信的前提。

    • 交互模式: 指令-响应握手。

  6. 信息服务族 (查询/透传): UECapabilityEnquiry/Information, UEInformationRequest/Response, DL/ULInformationTransfer

    • 使命: 信息交互的“辅助通道”。用于获取UE的静态能力、历史报告，以及为非RRC层提供透明传输服务。

    • 交互模式: 灵活的查询-响应，或单向的信息传递。

  7. 特定功能族: MBS相关消息, IAB消息, Sidelink消息等。

    • 使命: 使能5G的各种高级特性。

    • 交互模式: 根据具体特性的需求而设计，通常包含配置、指示、报告等多种消息。

通过这个分类，我们可以清晰地看到，第六章虽然消息繁多，但其结构和逻辑是高度系统化的，每一条消息都在RRC状态机的运转中扮演着不可或缺的角色。掌握了这些消息的定义、参数和交互流程，就等于掌握了分析和解决5G空口信令问题的“金钥匙”。

FAQ环节

Q1：安全模式控制流程必须在RRC连接建立后立即执行吗？可以跳过吗？

A1：必须立即执行，且不可跳过（除非在特定测试场景或网络配置了不安全接入）。根据规范，gNB在收到RRCSetupComplete后，会立即发起安全模式控制流程。这是因为，UE在RRCSetupComplete中携带了初始NAS消息，该消息触发了核心网的安全上下文协商。一旦协商完成，gNB必须立即激活AS安全，以保护后续所有的信令（SRB1/2/3）和用户数据（DRBs）。在AS安全激活之前，SRB2和DRBs是不能被建立和使用的。

Q2：UE在RRC_CONNECTED状态下，如果需要获取某个“按需SIB”，是使用RRCSystemInfoRequest还是DedicatedSIBRequest？

A2：在RRC_CONNECTED状态下，UE使用**DedicatedSIBRequest-r16**来请求按需SIB。

  • RRCSystemInfoRequest: 是为**RRC_IDLE和RRC_INACTIVE**状态的UE设计的。它通过随机接入过程（Msg3）发送，是一种“公共”请求方式。

  • DedicatedSIBRequest-r16: 是为**RRC_CONNECTED**状态的UE设计的。它通过专用的信令承载（SRB1）发送，是一种“私有”请求方式。

这种区分设计，确保了不同状态下的UE都有最高效的信息获取路径。

Q3：SecurityModeComplete消息的完整性保护是如何实现的？此时双方的密钥不是才刚刚派生出来吗？

A3：这是一个“先有鸡还是先有蛋”的经典问题，协议设计得很巧妙。流程如下：

  1. gNB发送SecurityModeCommand。这条消息是未受完整性保护的。

  2. UE收到SecurityModeCommand后，使用已有的K_gNB密钥和指令中的算法，派生出用于SRB1完整性保护的密钥（K_RRC_int）。

  3. UE立即使用这个新派生的K_RRC_int密钥，计算SecurityModeComplete消息的完整性校验码（MAC-I），并将其附加在消息尾部发送出去。同时，UE底层的PDCP实体开始对所有后续上行SRB1消息进行完整性保护。

  4. gNB侧，在发送SecurityModeCommand后，也同步地派生出同样的K_RRC_int密钥。它在接收SecurityModeComplete时，使用这个密钥对消息进行完整性校验。

  5. 如果校验成功，说明UE正确地接收了指令并派生了正确的密钥。自此，双方在SRB1上的安全上下文达成一致。

Q4：如果网络更新了某个SIB的内容，处于IDLE/INACTIVE状态的UE如何知道需要去重新获取？

A4：UE通过监听寻呼（Paging）信道和检查SIB1的版本号来感知系统信息的变化。

  1. 寻呼通知: 当网络修改了任何系统信息时，它会在下一个修改周期（Modification Period）内，在Paging消息中包含一个systemInfoModification指示。所有IDLE/INACTIVE的UE在自己的寻呼时机监听到这个指示后，就知道SI发生了变化。

  2. 获取新SIB1: UE会立即去获取最新的SIB1。

  3. 检查valueTag: SIB1中有一个schedulingInfoList，其中为每个SI消息（如SIB2, SIB3等）都附带了一个valueTag。这个valueTag在每次对应SIB内容更新时都会改变。UE将收到的新valueTag与自己本地缓存的valueTag进行比较。

  4. 按需获取: 如果某个SIB的valueTag发生了变化，UE就知道只有这个SIB需要重新获取，而不需要获取所有SIB，从而节省了时间和功耗。

Q5：学习完第六章所有RRC消息后，对于一个通信工程师来说，最重要的实践技能是什么？

A5：最重要的实践技能是将信令日志与协议定义进行关联分析的能力。在实际工作中，无论是网络优化还是故障排查，我们面对的都是海量的、十六进制的信令日志（如QCAT、Probe等工具抓取的log）。

核心技能包括：

  • 快速定位关键消息: 能够从复杂的信令流中，迅速识别出标志流程开始、转折、结束的关键消息，如RRCSetupRequest、RRCReconfiguration（特别是包含mobilityControlInfo的）、RLF-Report等。

  • 参数级深入分析: 能够将日志中解析出的字段值，与第六章定义的ASN.1结构和字段含义一一对应。例如，看到MeasurementReport，要能分析出measId、触发事件类型、以及报告的邻区PCI和RSRP值，并据此判断切换决策是否合理。

  • 构建信令时序图: 能够基于日志，手动或借助工具画出UE与网络之间的完整信令交互时序图，并与协议定义的标准流程进行比对，从而发现超时、重传、消息乱序、参数配置错误等异常问题。

掌握了这项技能，第六章就不再是枯燥的“字典”，而是解决实际问题的强大“武器库”。

关系图谱