51学通信

深度解析 3GPP TS 3.331：5.3.4 Initial AS security activation & 5.3.5 RRC reconfiguration (Part 1 - 安全激活与基...

24分钟阅读

好的，遵照您的指令，我们继续对3GPP TS 38.331进行深度拆解。在上一篇文章中，我们已经完整地剖析了规范的“奠基篇”，涵盖了第一至三章，明确了RRC协议的范围、知识依赖和核心术语。

现在，我们的主角工程师阿哲，已经为他的“RRC宪法”研读之旅打下了坚实的基础。他知道，理论的基石已经稳固，是时候进入协议的核心——具体流程的世界了。他翻开了规范中最庞大、也最关键的第五章“流程”（Procedures）。

根据我们的拆解计划，本篇文章将聚焦于RRC连接建立后的第一组关键动作：为通信信道加装“数字盾牌”的初始AS安全激活（5.3.4节），以及挥舞起RRC连接态“瑞士军刀”——RRCReconfiguration消息，完成基础配置（5.3.5节 Part 1）的流程。我们将见证一个“裸奔”的初始连接，如何转变为一个安全、可靠且为数据传输和移动性做好充分准备的成熟连接。

深度解析 3GPP TS 3.331：5.3.4 Initial AS security activation & 5.3.5 RRC reconfiguration (Part 1 - 安全激活与基础配置)

本文技术原理深度参考了3GPP TS 38.331 V18.5.1 (2025-03) Release 18规范中，关于“5.3.4 Initial AS security activation (初始AS安全激活)”和“5.3.5 RRC reconfiguration (RRC重配置)”的第一部分核心章节，旨在为读者深入剖析RRC连接建立后，如何激活空口安全以及如何通过RRC重配置消息完成数据承载和测量等基础功能的配置。

在上一章的结尾，阿哲的手机刚刚完成了RRC连接建立的三步握手，成功进入RRC_CONNECTED状态。然而，此刻的连接还只是一个“毛坯房”——仅仅建立了一条基础的信令承载SRB1，既不安全（未加密），也无法传输用户数据（没有数据承载DRB）。阿哲打开的新闻App正在焦急地等待着网络数据的到来。

就在这短暂的等待中，RRC协议实体正在后台进行着至关重要的“精装修”工作。首先，也是最紧迫的，就是为这座通信的房子装上坚固的“防盗门和加密窗”——启动初始AS安全。

1. 铸造“数字盾牌”：初始AS安全激活 (解读5.3.4 Initial AS security activation)

在任何敏感信息（包括后续的NAS信令）和用户数据在空口传输之前，必须建立一个安全的通信环境。这就是初始AS（接入层）安全激活流程的使命。它为UE和gNB之间的通信提供了双重保障：完整性保护（防止信令被篡改）和加密（防止信令及数据被窃听）。

1.1 流程的目的与启动时机 (5.3.4.1 General & 5.3.4.2 Initiation)

The purpose of this procedure is to activate AS security upon RRC connection establishment.

The network initiates the security mode command procedure to a UE in RRC_CONNECTED… when only SRB1 is established, i.e. prior to establishment of SRB2, multicast MRBs and/ or DRBs.

规范明确指出，此流程的目标是在RRC连接建立后激活AS安全。网络侧（gNB）在从核心网（AMF）获取到UE的安全上下文（包含主密钥KAMF）后，便会立即启动此流程。启动的时机非常关键：仅在SRB1建立之后，且在任何其他承载（如SRB2、DRB）建立之前。

阿哲理解，这是一个逻辑上的必然：必须先有一条基础的信令通道（SRB1）来传输安全激活的指令，又必须在传输任何有价值的数据之前完成安全部署。

1.2 安全激活的两步交互

整个流程是一个简洁高效的两步握手，如规范中的Figure 5.3.4.1-1: Security mode command, successful所示。

步骤一：网络的指令 - SecurityModeCommand

gNB向UE发送SecurityModeCommand消息。这相当于网络下达的一道“启动最高级别安保”的命令。

5.3.4.3 Reception of the SecurityModeCommand by the UE The UE shall: 1> derive the KgNB key, as specified in TS 33.501; 1> derive the KRRCint key associated with the integrityProtAlgorithm indicated in the SecurityModeCommand message…

当阿哲的手机收到这条指令后，RRC协议实体会执行一系列精密的操作：

  1. 密钥派生：这是整个安全流程的核心。UE会使用从NAS层获取的根密钥KAMF，根据3GPP TS 33.501中定义的密钥派生算法，计算出一系列用于AS层的密钥：

    • KgNB: gNB的基密钥。
    • KRRCint: 用于RRC信令完整性保护的密钥。
    • KRRCenc: 用于RRC信令加密的密钥。
    • KUPint: 用于用户数据完整性保护的密钥（如果启用）。
    • KUPenc: 用于用户数据加密的密钥。

  2. 完整性校验：SecurityModeCommand消息本身是不加密但受完整性保护的。UE会使用刚刚派生出的KRRCint密钥和消息中指定的完整性算法，对收到的消息进行校验。

    request lower layers to verify the integrity protection of the SecurityModeCommand message, using the algorithm indicated… and the KRRCint key;

    阿哲马上意识到这一步的巧妙之处：这既是对消息本身的一次防篡改校验，也是对双方密钥是否一致的一次“隔空验证”。如果UE能用自己计算出的密钥成功解开消息的完整性“封条”，就证明它和网络拥有相同的根密钥，安全上下文是对的。

  3. 配置下层：如果完整性校验通过，UE会立即配置下层（主要是PDCP层）：

    • 立即启用完整性保护：

      configure lower layers to apply SRB integrity protection… immediately, i.e. integrity protection shall be applied to all subsequent messages received and sent by the UE, including the SecurityModeComplete message;

    • 准备启用加密：

      configure lower layers to apply SRB ciphering… after completing the procedure, i.e. ciphering shall be applied to all subsequent messages received and sent by the UE, except for the SecurityModeComplete message which is sent unciphered;

    这里有一个非常精妙的时序设计：完整性保护是立即生效的，包括即将发送的响应消息SecurityModeComplete。而加密则要等到整个流程完成后（即发送完SecurityModeComplete之后）才对后续消息生效。

步骤二：UE的确认 - SecurityModeComplete

在完成上述所有配置后，UE会向gNB回复一条SecurityModeComplete消息。这条消息本身受完整性保护，但不加密。

阿哲思考着为什么是这样的设计：

  • 完整性保护：向网络证明UE已经成功派生并应用了正确的KRRCint密钥。
  • 不加密：因为此时网络侧还不知道UE是否已成功配置，尚未启动解密功能。如果UE加密了这条消息，网络将无法解密。这条未加密但完整性校验通过的消息，本身就是“加密已准备就緒”的明确信号。

当gNB成功接收并校验通过SecurityModeComplete消息后，双方的安全通道就正式建立。此后，所有在SRB1上传输的RRC信令都将被加密和完整性保护。阿哲手机的通信“毛坯房”终于装上了坚固的门窗。

2. RRC的“瑞士军刀”：RRC重配置流程 (解读5.3.5 RRC reconfiguration)

安全通道已建立，接下来就该为阿哲的新闻App铺设真正的数据传输管道了。此时，RRC协议中最强大、最通用的工具——RRCReconfiguration消息，正式登场。

2.1 RRCReconfiguration的万能角色 (5.3.5.1 General)

The purpose of this procedure is to modify an RRC connection, e.g. to establish/modify/release RBs…, to perform reconfiguration with sync, to setup/modify/release measurements, to add/modify/release SCells and cell groups…

这一段话揭示了RRCReconfiguration的“万能”本质。在RRC_CONNECTED状态下，几乎所有对UE无线资源的静态或动态修改，都通过这一个流程来完成。它就像一把瑞士军刀，集成了多种工具：

  • 承载管理：建立、修改、释放SRBs和DRBs。
  • 移动性控制：执行切换（Handover）。
  • 测量管理：配置、修改、释放测量任务。
  • 多载波管理：添加、修改、释放CA的辅小区（SCell）或DC的辅小区组（SCG）。
  • 其他配置：更新安全密钥、配置Sidelink、配置LTM等高级功能。

本篇文章作为系列的第一部分，我们首先聚焦于它在连接建立后的两个最基础、最常见的应用：无线承载配置和测量配置。

2.2 铺设数据高速公路：无线承载配置 (解读5.3.5.6 Radio Bearer configuration)

阿哲的新闻App需要下载数据，核心网已经为他建立了一个PDU会话。现在，gNB需要通过RRC为这个PDU会话在空口上建立一个具体的数据承载（DRB）。

The UE shall perform the following actions based on a received RadioBearerConfig IE: 1> if the RadioBearerConfig includes the drb-ToAddModList: 2> perform DRB addition or reconfiguration as specified in 5.3.5.6.5;

gNB会向UE发送一个包含radioBearerConfig信息元素的RRCReconfiguration消息。UE收到后，会解析其中的drb-ToAddModList列表。

2.2.1 DRB的“三层结构”

对于列表中每一个需要新增的DRB，UE需要为其建立一个完整的L2协议栈实例，这是一个自上而下的配置过程：

  1. PDCP层配置 (5.3.5.6.5)

    establish a PDCP entity and configure it in accordance with the received pdcp-Config; UE首先会建立一个PDCP实体。pdcp-Config会告诉这个实体：

    • 是否启用头压缩（ROHC）以节省开销。
    • 是否启用乱序递交。
    • 安全参数：由于此时AS安全已激活，配置中会明确该DRB是否需要加密（cipheringDisabled）和完整性保护（integrityProtection）。

  2. RLC层配置 (5.3.5.5.4) PDCP实体处理完数据包后，会将其交给下层的RLC实体。RRCReconfiguration消息通过mac-LogicalChannelConfig中的rlc-BearerToAddModList来配置RLC。rlc-Config会指定RLC的工作模式：

    • AM (Acknowledged Mode)：可靠传输模式，有重传机制，适用于TCP等需要可靠交付的业务。
    • UM (Unacknowledged Mode)：不可靠传输模式，无重传，适用于VoIP、视频等实时业务。
    • TM (Transparent Mode)：透明模式，基本不做任何处理，用于SRB0等特殊场景。

  3. MAC层配置 (5.3.5.5.5) RLC实体处理后的数据单元会放入逻辑信道（Logical Channel）的缓冲区，等待MAC层调度。mac-LogicalChannelConfig会为这个DRB分配一个逻辑信道ID（logicalChannelIdentity），并配置其优先级、逻辑信道组等参数。MAC层会根据这些参数，在物理层资源可用时，进行调度和传输。

通过这三层配置，一条从核心网数据包到空口物理传输的完整“数据高速公路”就铺设完成了。阿哲的手机屏幕上，新闻App的图片和文字开始流畅地加载出来。

2.2.2 SRB2的建立

通常，在建立第一个DRB的同一个RRCReconfiguration消息中，网络也会包含建立SRB2的配置（通过srb-ToAddModList）。SRB2的建立过程与DRB类似，也需要配置PDCP、RLC和逻辑信道，但它的配置通常使用默认值或标准值，因为它专门用于传输NAS信令。

2.3 未雨绸缪：测量配置 (逻辑关联5.5.2)

阿哲一边看新闻，一边开始在房间里走动。gNB无法预知他是否会走出当前小区的覆盖范围，因此必须未雨绸缪，让UE扮演“侦察兵”的角色，时刻监控周边环境。RRCReconfiguration消息通过携带measConfig IE来下达“侦察任务”。

1> if the RRCReconfiguration message includes the measConfig: 2> perform the measurement configuration procedure as specified in 5.5.2;

measConfig是RRC中另一个极其复杂的配置结构，它定义了移动性管理的“游戏规则”。其核心是“三驾马车”模型：

  1. measObjectToAddModList (测量对象)：回答“测什么”的问题。

    • 一个MeasObject可以定义一个需要测量的载波频率，包括其频点、子载波间隔、SSB测量时窗（SMTC）等。
    • 网络可以配置多个MeasObject，让UE同时监控多个同频或异频的邻区。

  2. reportConfigToAddModList (报告配置)：回答“何时报、如何报”的问题。

    • 一个ReportConfig定义了触发测量报告的条件。最常见的类型是事件触发（eventTriggered），例如：
      • Event A3: 邻区信号强度 > 服务小区信号强度 + 偏置量。这是最常用的切换触发事件。
      • Event A2: 服务小区信号强度 < 某个门限。用于检测服务小区信号恶化。
      • Event A5: 服务小区 < 门限1 且 邻区 > 门限2。常用于覆盖边缘的切换决策。
    • 报告配置还定义了报告的内容，比如需要上报RSRP、RSRQ还是SINR。

  3. measIdToAddModList (测量ID)：回答“将‘测什么’和‘如何报’关联起来”的问题。

    • 一个MeasId将一个measObjectId和一个reportConfigId链接在一起，构成一个完整的测量任务。
    • 例如，网络可以配置MeasId 1 = {measObjectId 1 (测量F1频率), reportConfigId 1 (使用A3事件)}；同时配置MeasId 2 = {measObjectId 1 (仍测量F1频率), reportConfigId 2 (使用周期性上报)}。

通过这三者的组合，网络可以灵活地为UE定制出极其精细和复杂的测量策略。当阿哲的手机收到包含measConfig的RRCReconfiguration消息后，它就开启了“侦察兵”模式，在进行数据收发的同时，默默地在后台执行测量任务，为可能的切换做好准备。

结语：从“毛坯房”到“精装智能家居”

本篇文章，我们见证了RRC协议在连接建立后，如何通过两个关键流程，将一个基础的、不安全的连接，升级为一个功能完备的通信会话：

  1. 初始AS安全激活 (5.3.4)：通过SecurityModeCommand和SecurityModeComplete的交互，为通信通道铸造了坚不可摧的“数字盾牌”，确保了后续所有通信的机密性和完整性。
  2. RRC重配置 (5.3.5)：利用其“瑞士军刀”——RRCReconfiguration消息，完成了两项基础但关键的“装修”工作：
    • 铺设数据通路：通过radioBearerConfig为用户数据建立了从PDCP到MAC的完整协议栈，使得阿哲的应用数据得以在空口传输。
    • 部署监控系统：通过measConfig为UE下发了测量任务，使其化身“侦察兵”，为网络的移动性管理提供决策依据。

至此，阿哲的手机才真正进入了一个稳定、高效、安全的RRC_CONNECTED工作状态。然而，RRCReconfiguration的威力远不止于此。当阿哲走出家门，手机信号开始变化时，更为动态和复杂的RRC流程即将上演。在下一篇文章中，我们将继续深入5.3.5节，聚焦于其在移动性管理中的核心应用——切换（Handover），看RRC是如何导演一场无缝切换的精彩大戏。

FAQ

Q1：为什么SecurityModeComplete消息本身不加密？ A1：这是一个精妙的时序和逻辑设计。SecurityModeCommand的目的是让UE和gNB就加密算法和密钥达成一致并启用。当UE收到SecurityModeCommand并成功派生密钥后，它发送SecurityModeComplete来确认。此时，UE已经准备好加密，但gNB还无法确定UE是否已成功。如果UE加密了这条消息，gNB可能会因为尚未启用解密流程而无法正确解析，从而导致流程失败。因此，这条消息采用“完整性保护+不加密”的方式，gNB只要能通过完整性校验，就足以证明UE拥有了正确的密钥，并且已经准备就绪。收到这条消息后，gNB和UE就同步地认为安全已激活，后续的所有消息都将进行加密处理。

Q2：一个DRB（数据无线承载）和一个QoS流（QoS Flow）是什么关系？ A2：可以理解为“水管”和“水流”的关系。QoS流是5G核心网定义的端到端服务质量的基本单位，不同的QoS流有不同的特性（如时延、速率、可靠性要求）。DRB是空口上承载用户数据的无线通道。在5G中，一个或多个具有相似QoS要求的QoS流，可以被映射到同一个DRB上传输。这个映射关系由L2的SDAP（Service Data Adaptation Protocol）层来管理。RRC负责建立DRB这条“水管”，而SDAP则负责将来自核心网的不同“水流”（QoS流）引导到合适的“水管”中。

Q3：UE在进行测量时，会影响正常的数据收发吗？ A3：可能会有影响，RRC通过**测量间隙（Measurement Gap）**来管理这种影响。如果UE需要测量一个不同频段的邻区，并且它的射频硬件（RF）不支持在收发数据的主频和测量异频之间快速切换，网络就会通过RRCReconfiguration消息为UE配置测量间隙。这是一个短暂的时间窗口（通常是几毫秒），在此期间，UE会暂停在服务小区上的所有数据收发，将射频单元调谐到目标频率进行测量，完成后再迅速切换回来。RRC会精心设计测量间隙的模式和周期，以尽量减小对用户业务的冲击。

Q4：如果UE收到了一个RRCReconfiguration消息，但由于自身能力限制（如硬件不支持）而无法执行其中的某些配置，会发生什么？ A4：UE会向网络报告一次“重配置失败”。根据规范5.3.5.8.2节（Inability to comply with RRCReconfiguration），UE会拒绝应用整个消息，并向网络发送一条RRCReconfigurationFailure消息。UE会继续使用失败前的旧配置。这是一个“原子性”原则，即要么完全成功应用新配置，要么完全不应用并报告失败，以避免UE和网络之间的配置状态不一致，这种不一致是网络中许多疑难杂症的根源。

Q5：RRC重配置流程中的reconfigurationWithSync字段是什么作用？ A5：reconfigurationWithSync是触发同步重配置的关键标志，通常用于切换或需要重新与小区建立下行同步和上行同步的场景。当RRCReconfiguration消息中包含此字段时，意味着UE需要执行一个“硬切换”或“主小区变更”。UE会重置MAC层，释放与旧小区的所有连接，并根据消息中提供的同步信息（如SSB索引）和RACH配置，向新的目标小区发起一次随机接入过程，以建立新的同步。不带此字段的重配置通常是“软”的或增量的修改，如添加一个SCell或修改一个DRB参数，这些操作不影响UE与PCell的同步状态。

关系图谱