深度解析 3GPP TS 38.331：第六章协议数据单元、格式与参数 (Part 1 - 总体结构与核心消息)

本文技术原理深度参考了3GPP TS 38.331 V18.5.0 (2025-03) Release 18规范中，关于“6 Protocol data units, formats and parameters (ASN.1)”的核心章节，旨在为读者提供一个关于RRC消息编码、结构、字段存在性规则以及关键RRC信令流程的详尽视图。

引言：RRC消息的“语法”与“词典”

欢迎来到3GPP规范的深度解读系列。本系列旨在将晦涩难懂的协议条文，转化为通信工程师和学生们能够轻松理解和应用的实践知识。今天，我们将开启对5G NR RRC协议（TS 38.331）核心的探索之旅，从第六章——“协议数据单元、格式与参数”开始。

如果说RRC协议是网络（gNB）与终端（UE）之间的“语言”，那么第六章就是这门语言的“语法书”和“词典”。它定义了每一个RRC消息的具体内容、编码方式和参数细节。理解了本章，就等于掌握了阅读和分析RRC信令的基础。

为了让整个解读过程更加生动具象，我们引入一个主角——5G终端“小明”。在接下来的文章中，我们将跟随小明的视角，看他手中的5G手机是如何通过解析和构造本章定义的各种RRC消息，来完成网络注册、数据传输、移动性管理等一系列复杂操作的。

1. 第六章概览：协议数据单元、格式与参数 (ASN.1)

第六章是整个RRC规范中篇幅最长、内容最密集的部分。它利用ASN.1（Abstract Syntax Notation One，抽象语法记法一）这套标准化的数据结构描述语言，来精确定义RRC消息的语法结构。

6.1节 介绍了ASN.1的使用规则，特别是“Need Codes”这一核心概念，它决定了可选字段在何种条件下必须出现，以及UE该如何处理缺失的字段。
6.2节 则开始逐一列举并定义所有的RRC消息，从广播信道承载的MIB、SIB，到专用信道承载的RRCSetup、RRCReconfiguration等。每个消息的定义都像是一本详尽的说明书。
6.3节 定义了RRC消息中可复用的信息元素（Information Elements, IEs），如RadioBearerConfig、MeasConfig等，提高了规范的模块化和可读性。

简单来说，本章为我们描绘了gNB和UE之间信息交互的“契约蓝图”。

2. 6.1 General (通用规则)

本节为理解所有RRC消息奠定了基础，它定义了如何阅读ASN.1语法、如何处理可选字段等通用规则。

2.1 6.1.1 Introduction (引言)

The contents of each RRC message is specified in clause 6.2 using ASN.1 to specify the message syntax and using tables when needed to provide further detailed information about the fields specified in the message syntax. The syntax of the information elements that are defined as stand-alone abstract types is further specified in a similar manner in clause 6.3.

这段原文明确指出，6.2节使用ASN.1来规定RRC消息的语法，6.3节则定义了可复用的信息元素（IEs）。ASN.1是UE与gNB之间沟通的“普通话”，确保了双方对消息结构有完全一致的理解。

想象一下，小明手中的手机收到一条RRCReconfiguration消息，手机的RRC协议栈需要像一个精通ASN.1语法的“解码器”，准确地解析出其中包含的每一个参数，比如要添加哪个小区作为辅小区、新的无线承载参数是什么等等。

Usage of the text “Network always configures the UE with a value for this field” in the field description indicates that the network has to provide a value for the field in this or in a previous message based on delta configuration (for an optional field with Need M). It does not imply a mandatory presence of the field.

这里提到了一个重要的概念——增量配置（delta configuration）。网络不必在每条消息中都发送所有配置。例如，如果网络在第一条消息中配置了某个参数，在后续消息中只要这个参数不变，就可以省略它。而Need M（Maintain）这个规则（稍后详述）正是实现增量配置的关键。

2.2 6.1.2 Need codes and conditions for optional fields (可选字段的需求码和条件)

在ASN.1定义中，很多字段被标记为OPTIONAL（可选）。但这并不意味着网络可以随意决定是否发送它们。“Need Codes”（需求码）就是附加在OPTIONAL字段上的“注释”，用来精确指导UE的行为。

The need for fields to be present in a message or an abstract type, i.e., the ASN.1 fields that are specified as OPTIONAL in the abstract notation (ASN.1), is specified by means of comment text tags attached to the OPTIONAL statement in the abstract syntax. All comment text tags are available for use in the downlink direction for RRC message and in the sidelink for PC5 RRC message. The meaning of each tag is specified in table 6.1.2-1.

这些需求码是理解RRC信令行为的关键。如果一个字段根据条件是强制性的，但网络却没有发送，UE会认为这是网络行为错误，而不需要去执行复杂的错误处理流程。

下面，我们通过规范原文的Table 6.1.2-1来逐一解析这些需求码的含义。

2.2.1 表格 6.1.2-1 深度解析

这张表格定义了用于指定字段是否需要出现的缩写词的含义，是RRC协议的“潜规则”说明书。

1:1 重绘 Markdown 表格：

Abbreviation	Meaning
Cond conditionTag	Conditionally present Presence of the field is specified in a tabular form following the ASN.1 segment.
CondC conditionTag	Configuration condition Presence of the field is conditional to other configuration settings.
CondM conditionTag	Message condition Presence of the field is conditional to other fields included in the message.
Need S	Specified Used for (configuration) fields, whose field description or procedure specifies the UE behavior performed upon receiving a message with the field absent (and not if field description or procedure specifies the UE behavior when field is not configured).
Need M	Maintain Used for (configuration) fields that are stored by the UE i.e. not one-shot. Upon receiving a message with the field absent, the UE maintains the current value.
Need N	No action (one-shot configuration that is not maintained) Used for (configuration) fields that are not stored and whose presence causes a one-time action by the UE. Upon receiving message with the field absent, the UE takes no action.
Need R	Release Used for (configuration) fields that are stored by the UE i.e. not one-shot. Upon receiving a message with the field absent, the UE releases the current value.

深度解读与场景化举例：

假设小明的手机正在与gNB进行RRC交互，我们来看看这些需求码是如何影响手机行为的。

Cond conditionTag (条件性出现): 字段是否出现，取决于一个复杂的条件判断。规范通常会在ASN.1代码块后面附带一个表格，详细说明在各种条件下，该字段是否存在，以及如果不存在UE该怎么办。例如，在RRCReconfiguration消息中，secondaryCellGroup字段的出现条件就取决于是否配置了双连接（NR-DC/NE-DC）。
Need S (Specified, 特殊指定): 字段缺失时的行为由规范中的具体流程或字段描述来指定。这是一个“特事特办”的规则。比如，某个字段缺失可能意味着UE需要采用一个默认值，或者执行一个特定的回退操作。
Need M (Maintain, 保持): 这是实现增量配置的核心。如果一个字段被标记为Need M，当小明的手机在后续的RRCReconfiguration消息中没有看到这个字段时，它会保持之前已经配置好的值。
- 场景: gNB第一次给小明配置了MeasObjectNR（测量对象），其中包含了载波频率等信息。这个IE被标记为Need M。之后，gNB又发送了一条RRCReconfiguration消息用于修改其他参数，但没有包含MeasObjectNR。此时，小明的手机会继续使用旧的MeasObjectNR配置进行测量，而不是删除它。这大大减少了信令开销。
Need R (Release, 释放): 与Need M相反。如果一个字段被标记为Need R，当小明的手机在消息中没有看到这个字段时，它会释放或删除这个配置。
- 场景: 小明之前被配置了一个用于NR辅小区的SCellConfig，该配置由Need R修饰。后来，gNB决定释放这个辅小区，它只需要发送一条不包含该SCellConfig的RRCReconfiguration消息即可。小明的手机收到后，就会自动删除这个辅小区的配置。
Need N (No action, 无动作): 这类字段通常用于触发一次性动作。如果消息中包含该字段，UE就执行一个动作；如果消息中不包含，UE就什么也不做。这种配置不会被UE存储。
- 场景: DLInformationTransfer消息中携带的dedicatedNAS-Message字段，就是一个典型的Need N字段。小明的手机收到这个字段后，会把NAS消息透传给上层，这个动作就完成了。它不会存储这个NAS消息。如果下一条DLInformationTransfer没有这个字段，手机也无需任何操作。

NOTE: In this version of the specification, the condition tags CondC and CondM are not used.

规范附注，CondC（配置条件）和CondM（消息条件）在本版规范中并未使用，我们可以暂时忽略。

2.3 6.1.3 General rules (通用规则)

Upon reception of a list not using ToAddModList and ToReleaseList structure, the UE shall delete all entries of the list currently in the UE configuration before applying the received list and shall consider each entry as newly created. This applies also to lists whose size is extended … This implies that Need M should not be used for fields in the entries of these lists; if used, UE will handle such fields equivalent to a Need R.

这是一个非常重要的“列表处理”规则。在RRC消息中，有两种列表更新方式：

全量替换: 如果一个列表不是通过ToAddModList（增改列表）和ToReleaseList（释放列表）结构来定义的，那么每次收到这个列表，UE都会先清空旧列表，再用新列表的内容完全替换。
差量更新: 使用ToAddModList和ToReleaseList结构，可以精确地增加、修改或删除列表中的某些条目，而无需发送整个列表。

这条规则指出，对于“全量替换”的列表，其中的字段即使被标记为Need M，UE也应该按Need R来处理。因为整个列表都被替换了，单个条目“保持”其旧值已经没有意义。

3. 6.2 RRC messages (RRC消息)

这一节是RRC协议的“消息主体词典”，定义了所有UE与gNB之间交互的RRC消息。

3.1 6.2.1 General message structure (通用消息结构)

本节按照消息承载的逻辑信道类型，对RRC消息进行了分类。逻辑信道决定了消息的“发送路径”和“用途”。

– NR-RRC-Definitions This ASN.1 segment is the start of the NR RRC PDU definitions.

这里声明了NR RRC协议数据单元（PDU）定义的开始。

RRC消息分类：

BCCH-BCH-Message: 承载在广播控制信道（BCCH）到广播信道（BCH）上。这是最基础的广播消息，只包含一个内容——MIB（主信息块）。
- 场景: 小明的手机开机后，第一件事就是监听BCH，从中解码出MIB。MIB就像一个“路标”，告诉手机最关键的系统帧号、子载波间隔以及如何找到SIB1。
BCCH-DL-SCH-Message: 承载在广播控制信道（BCCH）到下行共享信道（DL-SCH）上。主要用于承载SIB（系统信息块）。
- 场景: 小明通过MIB找到了SIB1的位置，然后在DL-SCH上解码BCCH-DL-SCH-Message，从而得到SIB1。SIB1是系统信息的“目录”，包含了小区接入信息、其他SIB的调度信息等。
DL-CCCH-Message: 承载在下行公共控制信道（DL-CCCH）上。用于RRC连接建立过程中的下行消息，如RRCSetup、RRCReject。
- 场景: 小明发送了RRCSetupRequest后，gNB会在DL-CCCH上回应一条DL-CCCH-Message。如果网络接纳小明，这条消息里会包含RRCSetup；如果拒绝，则包含RRCReject。
DL-DCCH-Message: 承载在下行专用控制信道（DL-DCCH）上。这是UE建立RRC连接后，用于接收网络专用配置的核心信道，承载了绝大多数的专用信令，如RRCReconfiguration、SecurityModeCommand等。
- 场景: 小明连接成功后，网络通过DL-DCCH-Message承载的RRCReconfiguration消息，为他配置数据承载、测量任务、切换指令等。
PCCH-Message: 承载在寻呼控制信道（PCCH）上，用于发送Paging消息。
- 场景: 小明的手机处于空闲态（RRC_IDLE），此时有人给他打电话。核心网会发起寻呼，gNB通过PCCH发送Paging消息，“呼唤”小明的手机。
UL-CCCH-Message: 承载在上行公共控制信道（UL-CCCH）上。用于UE在RRC连接建立或恢复过程中的上行初始消息，如RRCSetupRequest、RRCReestablishmentRequest。
UL-DCCH-Message: 承载在上行专用控制信道（UL-DCCH）上。用于UE在连接态下向网络发送响应和报告，如RRCReconfigurationComplete、MeasurementReport。

此外，还有用于多播/广播（MCCH, MulticastMCCH, PCCH）和上行CCCH1（UL-CCCH1）的特定消息类别。这些分类构成了RRC信令交互的骨架。

3.2 6.2.2 Message definitions (消息定义)

本节是核心中的核心，我们将逐一深入解读几个关键的RRC消息。

3.2.1 – CounterCheck (计数器检查)

The CounterCheck message is used by the network to indicate the current COUNT MSB values associated to each DRB and to request the UE to compare these to its COUNT MSB values and to report the comparison results to the network.

目的: 这是PDCP层的一项安全机制，用于检测潜在的重放攻击或COUNT值同步丢失问题。
承载: SRB1, RLC AM模式, DCCH。
方向: 网络 → UE。

场景: 小明正在使用手机进行数据通信。网络侧的PDCP实体为每个数据无线承载（DRB）维护一个发送序列号（COUNT值），小明手机侧的PDCP实体也为接收维护一个COUNT值。正常情况下，两边的COUNT值应该是同步增长的。如果网络怀疑同步性丢失（例如，长时间的无线链路中断后恢复），它会启动CounterCheck流程。

消息结构 (ASN.1):

CounterCheck ::= SEQUENCE {
    rrc-TransactionIdentifier     RRC-TransactionIdentifier,
    criticalExtensions            CHOICE {
        counterCheck              CounterCheck-IEs,
        criticalExtensionsFuture  SEQUENCE {}
    }
}
 
CounterCheck-IEs ::= SEQUENCE {
    drb-CountMSB-InfoList         DRB-CountMSB-InfoList,
    lateNonCriticalExtension      OCTET STRING OPTIONAL,
    nonCriticalExtension          SEQUENCE {} OPTIONAL
}
 
DRB-CountMSB-InfoList ::= SEQUENCE (SIZE (1..maxDRB)) OF DRB-CountMSB-Info
 
DRB-CountMSB-Info ::= SEQUENCE {
    drb-Identity                  DRB-Identity,
    countMSB-Uplink               INTEGER(0..33554431),
    countMSB-Downlink             INTEGER(0..33554431)
}

关键参数解读:

rrc-TransactionIdentifier: 事务标识符，用于匹配请求和响应。
drb-CountMSB-InfoList: 一个列表，包含了网络侧认为的、一个或多个DRB的COUNT值最高有效位（MSB）。
- drb-Identity: DRB的ID。
- countMSB-Uplink / countMSB-Downlink: 网络侧记录的、该DRB的上行/下行COUNT值的25个最高有效位（MSBs）。PDCP的COUNT值是32位，这里只传递高位用于快速校验。

小明的手机收到CounterCheck消息后，会用自己本地存储的COUNT值MSB与消息中的值进行比较。如果发现不匹配，就在后续的CounterCheckResponse消息中报告这些不匹配的DRB列表。网络收到报告后，可能会采取重置PDCP、重建承载等恢复措施。

3.2.2 – CounterCheckResponse (计数器检查响应)

The CounterCheckResponse message is used by the UE to respond to a CounterCheck message.

目的: 响应CounterCheck消息，向网络报告COUNT值的比对结果。
承载: SRB1, RLC AM模式, DCCH。
方向: UE → 网络。

消息结构 (ASN.1):

CounterCheckResponse ::= SEQUENCE {
    rrc-TransactionIdentifier     RRC-TransactionIdentifier,
    criticalExtensions            CHOICE {
        counterCheckResponse      CounterCheckResponse-IEs,
        criticalExtensionsFuture  SEQUENCE {}
    }
}
 
CounterCheckResponse-IEs ::= SEQUENCE {
    drb-CountInfoList             DRB-CountInfoList,
    lateNonCriticalExtension      OCTET STRING OPTIONAL,
    nonCriticalExtension          SEQUENCE {} OPTIONAL
}
...

关键参数解读:

drb-CountInfoList: 报告存在COUNT值不匹配的DRB列表。如果所有DRB都匹配，这个列表可以为空。UE在报告中会包含自己本地的完整COUNT值，以便网络进行精确校准。

3.2.3 – RRCReestablishment (RRC重建)

The RRCReestablishment message is used to re-establish SRB1.

目的: 在发生无线链路失败（RLF）后，用于恢复SRB1，并为后续恢复其他承载做准备。这是一种快速恢复机制，避免了从头开始建立RRC连接的漫长过程。
承载: SRB1（重建后）, RLC AM模式, DCCH。
方向: 网络 → UE。

场景: 小明的手机信号突然中断（比如进入电梯），触发了无线链路失败（RLF）。手机会立即尝试在当前频率或其他频率上寻找一个合适的小区，并发送RRCReestablishmentRequest消息。如果找到的小区（可以是原小区或新小区）拥有小明的上下文（UE context），它就会回应RRCReestablishment消息。

消息结构 (ASN.1):

RRCReestablishment ::= SEQUENCE {
    rrc-TransactionIdentifier         RRC-TransactionIdentifier,
    criticalExtensions                CHOICE {
        rrcReestablishment            RRCReestablishment-IEs,
        criticalExtensionsFuture      SEQUENCE {}
    }
}
 
RRCReestablishment-IEs ::= SEQUENCE {
    nextHopChainingCount              NextHopChainingCount,
    lateNonCriticalExtension          OCTET STRING OPTIONAL,
    nonCriticalExtension              RRCReestablishment-v1700-IEs OPTIONAL
}

关键参数解读:

nextHopChainingCount (NCC): 这是安全相关的关键参数。UE和gNB之间维护着一套安全密钥。为了保证前向安全，密钥会不断更新。NCC就是用于密钥链推导的计数器。网络在重建消息中提供这个参数，让UE能够同步到最新的安全状态，重新建立加密和完整性保护。

流程简述:

UE发生RLF，发送RRCReestablishmentRequest。
网络收到请求，如果找到UE上下文，则发送RRCReestablishment。
UE收到RRCReestablishment后，基于nextHopChainingCount重新建立SRB1的安全上下文。
UE发送RRCReestablishmentComplete，确认SRB1恢复成功。
之后，网络会通过RRCReconfiguration消息，恢复数据承载（DRBs）和SRB2/3。

这个过程比完整的RRC连接建立要快得多，因为它跳过了能力交互、初始安全激活等多个步骤，是保证业务连续性的重要机制。如果网络找不到UE上下文，它会拒绝重建请求，UE只能发起全新的RRC连接建立过程。

由于篇幅限制，我们今天重点解读了第六章的总体结构、ASN.1需求码规则以及几个基础且关键的RRC消息。后续文章将继续深入到RRCReconfiguration、RRCSetup等更复杂、更核心的消息定义中。

FAQ环节

Q1：ASN.1中的Need M和Need R有什么本质区别？为什么需要这两种机制？ A1：Need M（Maintain）和Need R（Release）是管理UE配置的两种核心机制，共同服务于“增量配置”（Delta Configuration）以减少信令开销。本质区别在于当字段缺失时UE的默认行为：

Need M: 字段缺失时，UE保持该字段的现有配置。这适用于那些一旦配置就不常变动的参数，网络后续只想修改其他参数时，就可以省略这些Need M字段。
Need R: 字段缺失时，UE释放或删除该字段的现有配置。这为网络提供了一种简洁的删除配置的方式，无需显式地发送“删除”指令。这两种机制让RRC重配消息变得非常灵活和高效。

Q2：为什么RRC消息要按照BCCH、CCCH、DCCH等不同逻辑信道进行分类？ A2：这种分类是基于消息的不同“使命”和“受众”。

BCCH (广播控制信道): 像“公共广播电台”，承载MIB/SIB，所有在小区覆盖范围内的UE都需要接收，内容是公开的、通用的。
CCCH (公共控制信道): 像“临时公共热线”，用于还没有建立专用联系的UE与网络进行初始沟通，例如发起连接请求(RRCSetupRequest)或接收连接建立指令(RRCSetup)。通信双方还没有分配专用的资源。
DCCH (专用控制信道): 像“私人电话专线”，一旦UE连接成功，就通过这个信道进行一对一的私密通信，传输针对该UE的特定配置、指令和报告。这种分工确保了信令传输的有序和高效。

Q3：CounterCheck流程在实际网络中频繁发生吗？它主要防范什么问题？ A3：CounterCheck流程在正常网络条件下不频繁发生。它是一个异常处理流程，主要用于维护PDCP层的安全同步性。它主要防范两种问题：

重放攻击 (Replay Attack): 恶意设备截获合法数据包后重新发送，企图欺骗接收方。通过检查不断增长的COUNT序列号，可以发现过时的重放包。
失去同步 (Loss of Synchronization): 在无线链路长时间中断、切换失败后恢复等场景下，UE和gNB两侧的COUNT值可能不再同步。这会导致解密失败或完整性校验失败。CounterCheck可以主动发现这种不同步，并触发恢复流程。

Q4：RRC重建(RRCReestablishment)和RRC恢复(RRCResume)有什么区别？ A4：两者都是从非连接状态恢复到连接态的快速机制，但触发场景和状态不同：

RRC重建 (RRCReestablishment): 由RRC_CONNECTED态下的无线链路失败 (RLF) 触发。UE此时认为连接仍然存在，只是链路暂时断了，它是在“抢救”一个已有的连接。成功后，UE保持在RRC_CONNECTED态。
RRC恢复 (RRCResume): 由RRC_INACTIVE态下的UE发起。UE主动挂起连接进入RRC_INACTIVE低功耗状态，当有上行数据要发送时，它发起Resume流程来“唤醒”连接。这是一个正常的状态转换。简单比喻，重建是“急救”，恢复是“睡醒了回来上班”。

Q5：ASN.1定义中的nonCriticalExtension字段有什么作用？ A5：nonCriticalExtension是实现RRC协议前向兼容性的关键设计。它允许3GPP在未来的协议版本中，向一个已有的RRC消息结构中添加新的参数，而不会影响旧版本UE的正常工作。

工作原理: 当一个旧版本的UE（比如Rel-15的UE）收到了一个包含了Rel-16新参数的nonCriticalExtension的消息时，由于它不认识这些新参数，它会直接忽略nonCriticalExtension中的所有内容，但仍然可以正常解析和处理消息中它认识的其他部分。
好处: 这保证了网络的平滑升级。新部署的gNB可以使用新版协议功能，而老旧的UE仍然可以在这个网络中正常工作，只是无法使用新功能而已。

51学通信

探索

深度解析 3GPP TS 38.331：第六章协议数据单元、格式与参数 (Part 1 - 总体结构与核心消息)

深度解析 3GPP TS 38.331：第六章协议数据单元、格式与参数 (Part 1 - 总体结构与核心消息)

引言：RRC消息的“语法”与“词典”

1. 第六章概览：协议数据单元、格式与参数 (ASN.1)

2. 6.1 General (通用规则)

2.1 6.1.1 Introduction (引言)

2.2 6.1.2 Need codes and conditions for optional fields (可选字段的需求码和条件)

2.2.1 表格 6.1.2-1 深度解析

2.3 6.1.3 General rules (通用规则)

3. 6.2 RRC messages (RRC消息)

3.1 6.2.1 General message structure (通用消息结构)

3.2 6.2.2 Message definitions (消息定义)

3.2.1 – CounterCheck (计数器检查)

3.2.2 – CounterCheckResponse (计数器检查响应)

3.2.3 – RRCReestablishment (RRC重建)

FAQ环节

关系图谱

目录

51学通信

探索

深度解析 3GPP TS 38.331：第六章 协议数据单元、格式与参数 (Part 1 - 总体结构与核心消息)

深度解析 3GPP TS 38.331：第六章 协议数据单元、格式与参数 (Part 1 - 总体结构与核心消息)

引言：RRC消息的“语法”与“词典”

1. 第六章概览：协议数据单元、格式与参数 (ASN.1)

2. 6.1 General (通用规则)

2.1 6.1.1 Introduction (引言)

2.2 6.1.2 Need codes and conditions for optional fields (可选字段的需求码和条件)

2.2.1 表格 6.1.2-1 深度解析

2.3 6.1.3 General rules (通用规则)

3. 6.2 RRC messages (RRC消息)

3.1 6.2.1 General message structure (通用消息结构)

3.2 6.2.2 Message definitions (消息定义)

3.2.1 – CounterCheck (计数器检查)

3.2.2 – CounterCheckResponse (计数器检查响应)

3.2.3 – RRCReestablishment (RRC重建)

FAQ环节

关系图谱

目录

深度解析 3GPP TS 38.331：第六章协议数据单元、格式与参数 (Part 1 - 总体结构与核心消息)

深度解析 3GPP TS 38.331：第六章协议数据单元、格式与参数 (Part 1 - 总体结构与核心消息)