好的，我们继续深入3GPP TS 38.331规范的第六章。在上一篇文章中，我们了解了RRC消息的通用规则和基本分类。现在，我们将从6.2.2节“消息定义”开始，逐一剖析那些在网络与终端交互中扮演关键角色的RRC消息。

深度解析 3GPP TS 38.331：第六章协议数据单元、格式与参数 (Part 2 - 核心下行消息与失败报告)

本文技术原理深度参考了3GPP TS 38.331 V18.5.0 (2025-03) Release 18规范中，关于“6.2.2 Message definitions”的核心章节，旨在为读者揭示RRC连接态下，UE如何请求特定系统信息、网络如何传递NAS层信令、如何处理超大RRC消息以及UE如何上报各类失败信息的具体信令流程与参数细节。

前情回顾与本章主角

在上一部分，我们的主角——5G终端“小明”的手机完成了开机后最基本的操作：通过解码MIB和SIB1，了解了小区的基本情况。现在，小明的手机已经成功进入了RRC_CONNECTED（RRC连接态），与网络建立了一条专用的信令通道。

在本章中，我们将聚焦于连接态下的一些核心交互。小明可能需要获取一些不常广播的特殊系统信息（比如高精度定位相关的），网络可能需要向小明下发上层（NAS）的指令，或者小明在游戏过程中遇到了无线链路问题需要向网络“投诉”。这些场景都离不开我们今天要解析的RRC消息。

1. DedicatedSIBRequest (专用SIB请求)

The DedicatedSIBRequest message is used to request SIB(s) required by the UE in RRC_CONNECTED as specified in clause 5.2.2.3.5.

解读与场景：

通常，系统信息（SIBs）是在广播信道上周期性发送的，供小区内的所有UE读取。但为了节省空口资源，一些不常用或者仅对特定UE有用的SIB（例如与特定定位技术相关的posSIB）可能不会被周期广播，这就是所谓的“按需SIB”（On-Demand SIB）。当处于RRC_CONNECTED态的小明需要这些信息时，他的手机就需要主动向网络发送一个DedicatedSIBRequest消息来“点播”这些SIB。

场景: 小明打开了一个需要高精度定位服务的应用，比如室内导航或者AR游戏。应用通知手机的定位引擎，需要获取GNSS辅助数据。手机的RRC层发现，这些辅助数据承载在posSIB-Type1-1中，而这个SIB并未在当前小区广播。于是，小明的手机立即构造并发送一条DedicatedSIBRequest消息给gNB，明确表示：“我需要posSIB-Type1-1，请发给我。”

信令承载: SRB1
RLC-SAP: AM
逻辑信道: DCCH
方向: UE to Network

1.1 消息结构 (ASN.1)

 
-- ASN1START
 
-- TAG-DEDICATEDSIBREQUEST-START
 
DedicatedSIBRequest-r16 ::=     SEQUENCE {
 
    criticalExtensions CHOICE {
 
        dedicatedSIBRequest-r16   DedicatedSIBRequest-r16-IEs,
 
        criticalExtensionsFuture  SEQUENCE {}
 
    }
 
}
 
DedicatedSIBRequest-r16-IEs ::= SEQUENCE {
 
    onDemandSIB-RequestList-r16     SEQUENCE {
 
        requestedSIB-List-r16           SEQUENCE (SIZE (1..maxOnDemandSIB-r16)) OF SIB-ReqInfo-r16 OPTIONAL,
 
        requestedPosSIB-List-r16        SEQUENCE (SIZE (1..maxOnDemandPosSIB-r16)) OF PosSIB-ReqInfo-r16 OPTIONAL
 
    } OPTIONAL,
 
    lateNonCriticalExtension        OCTET STRING OPTIONAL,
 
    nonCriticalExtension            SEQUENCE {} OPTIONAL
 
}
 
SIB-ReqInfo-r16 ::= ENUMERATED { sib12, sib13, sib14, sib20-v1700, sib21-v1700, sib23-v1810, spare2, spare1 }
 
PosSIB-ReqInfo-r16 ::= SEQUENCE {
 
    gnss-id-r16         GNSS-ID-r16 OPTIONAL,
 
    sbas-id-r16         SBAS-ID-r16 OPTIONAL,
 
    posSibType-r16      ENUMERATED {
 
                            posSibType1-1, posSibType1-2, posSibType1-3, posSibType1-4, posSibType1-5, posSibType1-6,
 
                            posSibType1-7, posSibType1-8, posSibType2-1, posSibType2-2, posSibType2-3, posSibType2-4,
 
                            ...
 
                        }
 
}
 
-- TAG-DEDICATEDSIBREQUEST-STOP
 
-- ASN1STOP

1.2 关键参数解读

| 字段名 | 描述 |

| :--- | :--- |

| requestedSIB-List | 包含UE在RRC_CONNECTED状态下请求的SIB列表。 |

| requestedPosSIB-List | 包含UE在RRC_CONNECTED状态下请求的posSIB列表。 |

1.2.1 `requestedSIB-List`

这个列表用于请求非定位相关的“按需SIB”。列表中的每一项都是SIB-ReqInfo-r16，它是一个枚举类型，直接列出了可以被请求的SIB类型，如sib12（与侧行通信Sidelink相关）、sib13等。

1.2.2 `requestedPosSIB-List`

这个列表专门用于请求与定位相关的posSIB。列表的每一项是PosSIB-ReqInfo-r16结构，其中包含了更详细的请求信息。

| 字段名 (PosSIB-ReqInfo-r16内) | 描述 |

| :--- | :--- |

| gnss-id | 该字段的存在表明请求的定位SIB类型是针对特定的GNSS（全球导航卫星系统）。它指明了具体的GNSS（参考TS 37.355）。 |

| sbas-id | 该字段的存在表明请求的定位SIB类型是针对特定的SBAS（星基增强系统）。它指明了具体的SBAS（参考TS 37.355）。如果UE包含此字段，它也应将gnss-id设置为sbas。 |

| posSibType-r16 | 这是一个庞大的枚举列表，精确定义了UE想要的具体posSIB类型，例如posSibType1-1可能包含GPS的辅助数据，posSibType1-2可能包含GLONASS的辅助数据等。 |

回到小明的场景，他的手机会填充requestedPosSIB-List，其中包含一个PosSIB-ReqInfo-r16条目，并将posSibType-r16设置为应用所需的posSibType1-1。网络收到后，会通过RRCReconfiguration消息，在dedicatedSystemInformationDelivery字段中将请求的SIB“专送”给小明的手机。

2. DLDedicatedMessageSegment (下行专用消息分片)

The DLDedicatedMessageSegment message is used to transfer one segment of the RRCResume or RRCReconfiguration messages.

解读与场景：

在5G中，随着特性越来越复杂（如载波聚合、双连接），一条RRCReconfiguration消息可能会变得非常大，甚至超过底层PDCP协议层能够处理的单个服务数据单元（SDU）的大小限制。为了解决这个问题，RRC层引入了“消息分片”机制。DLDedicatedMessageSegment就是用于传输这些被拆分后的大消息的“集装箱”。

场景: 小明的运营商刚刚为他开通了FR1+FR2的双连接功能。为了配置这个复杂的场景，gNB需要给小明的手机发送一条巨大的RRCReconfiguration消息，其中包含了FR2辅小区组（SCG）的所有配置。这条消息的大小超过了PDCP SDU的限制。于是，gNB的RRC层会将这条大消息切分成多个小片段，然后用一系列DLDedicatedMessageSegment消息，像快递包裹一样，一片一片地发送给小明的手机。

信令承载: SRB1
RLC-SAP: AM
逻辑信道: DCCH
方向: Network to UE

2.1 消息结构 (ASN.1)

 
DLDedicatedMessageSegment-r16 ::= SEQUENCE {
 
    criticalExtensions                  CHOICE {
 
        dlDedicatedMessageSegment-r16     DLDedicatedMessageSegment-r16-IEs,
 
        criticalExtensionsFuture          SEQUENCE {}
 
    }
 
}
 
DLDedicatedMessageSegment-r16-IEs ::= SEQUENCE {
 
    segmentNumber-r16                   INTEGER(0..4),
 
    rrc-MessageSegmentContainer-r16     OCTET STRING,
 
    rrc-MessageSegmentType-r16          ENUMERATED {notLastSegment, lastSegment},
 
    lateNonCriticalExtension            OCTET STRING OPTIONAL,
 
    nonCriticalExtension                SEQUENCE {} OPTIONAL
 
}

2.2 关键参数解读

| 字段名 | 描述 |

| :--- | :--- |

| segmentNumber | 标识已编码的DL DCCH消息中一个分片的序列号。网络以连续递增的segmentNumber顺序传输分片，因此UE的RRC层可以期望从下层以正确的顺序获取它们。因此，UE不需要在RRC层执行分片重排序。 |

| rrc-MessageSegmentContainer | 包含已编码的DL DCCH消息的一个分片。此容器中包含的分片的大小应足够小，以使最终编码的RRC消息PDU小于或等于PDCP SDU的大小限制。 |

| rrc-MessageSegmentType | 指示包含的DL DCCH消息分片是否是消息的最后一个分片。 |

小明的手机RRC层在收到第一个DLDedicatedMessageSegment后，会像拼图一样，根据segmentNumber将rrc-MessageSegmentContainer中的内容缓存起来。它会持续接收后续的分片，直到收到一个rrc-MessageSegmentType被标记为lastSegment的消息。此时，手机会将所有分片按顺序拼接起来，还原成一条完整的RRCReconfiguration消息，然后再进行解析和处理。

3. DLInformationTransfer (下行信息传输)

The DLInformationTransfer message is used for the downlink transfer of NAS dedicated information, timing information for the 5G internal system clock, or IAB-DU specific F1-C related information.

解读与场景：

DLInformationTransfer是RRC层的一个“通用信使”，它的主要任务是透明地传输上层（主要是NAS层）或其他非RRC协议的信息。RRC层只负责打包和可靠传输，对内容本身不进行解析。

场景: 小明正在上网，此时运营商的核心网（AMF）决定要修改他当前的PDU会话（比如调整QoS）。这个指令属于NAS层信令。AMF会将NAS消息发送给gNB，gNB的RRC层会把它封装在DLInformationTransfer消息的dedicatedNAS-Message字段中，然后通过DCCH发送给小明的手机。手机RRC层收到后，会把这个NAS消息原封不动地递交给手机的NAS层去处理。

信令承载: SRB2 或 SRB1 (仅当SRB2尚未建立时)。如果SRB2被挂起，网络会等到SRB2恢复后再发送此消息。
RLC-SAP: AM
逻辑信道: DCCH
方向: Network to UE

3.1 消息结构 (ASN.1)

 
DLInformationTransfer ::= SEQUENCE {
 
    rrc-TransactionIdentifier     RRC-TransactionIdentifier,
 
    criticalExtensions            CHOICE {
 
        dlInformationTransfer     DLInformationTransfer-IEs,
 
        criticalExtensionsFuture  SEQUENCE {}
 
    }
 
}
 
DLInformationTransfer-IEs ::= SEQUENCE {
 
    dedicatedNAS-Message          DedicatedNAS-Message OPTIONAL, -- Need N
 
    lateNonCriticalExtension      OCTET STRING OPTIONAL,
 
    nonCriticalExtension          DLInformationTransfer-v1610-IEs OPTIONAL
 
}
 
... (后续版本扩展)

3.2 关键参数解读

| 字段名 | 描述 |

| :--- | :--- |

| dedicatedNAS-Message | 包含UE特定的NAS层信息。这是一个Need N字段，表示UE收到后处理一次即可，无需存储。 |

| referenceTimeInfo-r16 | 用于传输5G内部系统时钟的时间信息。Need N。 |

| clockQualityDetailsLevel | 该字段指示TS 23.501中定义的时钟质量报告控制信息。 |

| eventID-TSS | 该字段指示TS 23.501中定义的5G接入层时间分发参数时钟质量报告控制信息的状态。 |

| sib9Fallback | 指示UE回退到接收SIB9中的referenceTimeInfo。Need N。 |

| ta-PDC | 指示UE侧基于TA的传播延迟补偿（PDC）是激活还是去激活。Need N。 |

这个消息的设计体现了分层原则，RRC专注于无线资源管理，而将非RRC的信令（如NAS信令、时间同步信息）通过这个“容器”消息进行透明传输。

4. FailureInformation (失败信息)

The FailureInformation message is used to inform the network about a failure detected by the UE.

解读与场景：

当UE在RRC_CONNECTED态检测到某些非致命的失败时（即失败不足以导致无线链路失败RLF），它可以使用FailureInformation消息向网络报告。这有助于网络进行故障诊断和性能优化。

场景: 小明正在进行一场紧张的电竞游戏，游戏数据通过DRB3传输。突然，手机的RLC层检测到在DRB3上连续多次重传失败，达到了最大重传次数。这个失败虽然影响了游戏体验，但并没有导致整个无线链路断开。于是，小明的手机会发送一条FailureInformation消息，告诉网络：“我在小区X，逻辑信道Y（对应DRB3）上遇到了RLC失败。”

信令承载: SRB1 或 SRB3
RLC-SAP: AM
逻辑信道: DCCH
方向: UE to Network

4.1 消息结构 (ASN.1)

 
FailureInformation ::= SEQUENCE {
 
    criticalExtensions            CHOICE {
 
        failureInformation        FailureInformation-IEs,
 
        criticalExtensionsFuture  SEQUENCE {}
 
    }
 
}
 
FailureInformation-IEs ::= SEQUENCE {
 
    failureInfoRLC-Bearer         FailureInfoRLC-Bearer OPTIONAL,
 
    lateNonCriticalExtension      OCTET STRING OPTIONAL,
 
    nonCriticalExtension          FailureInformation-v1610-IEs OPTIONAL
 
}
 
FailureInfoRLC-Bearer ::= SEQUENCE {
 
    cellGroupId                   CellGroupId,
 
    logicalChannelIdentity        LogicalChannelIdentity,
 
    failureType                   ENUMERATED {rlc-failure, spare3, spare2, spare1}
 
}
 
FailureInformation-v1610-IEs ::= SEQUENCE {
 
    failureInfoDAPS-r16           FailureInfoDAPS-r16 OPTIONAL,
 
    nonCriticalExtension          SEQUENCE {} OPTIONAL
 
}
 
FailureInfoDAPS-r16 ::= SEQUENCE {
 
    failureType-r16               ENUMERATED {daps-failure, spare3, spare2, spare1}
 
}

4.2 关键参数解读

failureInfoRLC-Bearer: 报告与RLC承载相关的失败。
- cellGroupId: 指示失败发生在哪个小区组（MCG或SCG）。
- logicalChannelIdentity: 发生失败的逻辑信道ID，网络可以据此定位到具体的DRB。
- failureType: 失败类型，目前主要是rlc-failure（RLC最大重传失败）。
failureInfoDAPS-r16: 报告与DAPS（双激活协议栈）切换相关的失败。

网络收到FailureInformation后，虽然不一定会立即为小明采取恢复措施，但可以将这些信息记录下来用于网络优化。例如，如果某个小区频繁上报RLC失败，网络运维人员可能会去排查该小区的干扰或覆盖问题。

5. 小结

今天我们深入探讨了RRC_CONNECTED态下的四种关键消息，它们分别代表了“请求”、“承载”、“封装”和“报告”四种典型的通信模式：

DedicatedSIBRequest: UE主动请求网络侧的特定信息。
DLDedicatedMessageSegment: RRC层为解决超大消息问题而设计的底层承载机制。
DLInformationTransfer: RRC层作为信使，为上层封装和透明传输信令。
FailureInformation: UE在遇到问题时，向网络主动报告失败情况。

理解这些消息的用途和结构，对于分析和定位连接态下的信令问题至关重要。在下一篇文章中，我们将迎来RRC协议中最为复杂和核心的消息——RRCReconfiguration，敬请期待！

FAQ环节

Q1：为什么处于RRC_CONNECTED态的UE还需要请求SIB？它不是应该已经获取了所有必要信息吗？

A1：这是为了网络效率。RRC_CONNECTED态的UE确实已经获取了维持连接所需的基本信息。但有些SIB（如定位SIB、Sidelink SIB等）内容庞大且不是所有UE都随时需要。如果网络持续广播这些SIB，会占用大量宝贵的空口资源。因此，3GPP引入了“按需SIB”（On-Demand SIB）机制，网络只广播一个“菜单”（在SIB1中指示哪些SIB是按需的），UE在RRC_CONNECTED态下如果确实需要，再通过DedicatedSIBRequest单独“点菜”，网络再“专送”给它。这是一种高效的资源利用方式。

Q2：DLInformationTransfer和RRCReconfiguration消息都可以从网络发往UE，它们在功能上有什么根本区别？

A2：根本区别在于消息的解析者和作用域：

DLInformationTransfer: RRC层是“信使”。它只是透明地传输消息内容（如NAS消息），自己不解析。消息的最终解析者是UE的NAS层或其他实体。它主要用于传递非RRC层面的控制信令。
RRCReconfiguration: RRC层是“执行官”。这条消息的内容是写给RRC层自己看的，包含了详细的无线资源配置指令（如添加/修改/删除小区、承载、测量等）。UE的RRC层收到后必须解析并执行这些配置。

Q3：RRC层的消息分片机制和底层RLC层的分段/级联机制有什么不同？

A3：两者都处理“大数据包”，但层面和目的不同：

RLC层分段/级联 (Segmentation/Concatenation): 这是RLC AM或UM模式的固有功能。它将上层（PDCP）递交下来的任意大小的PDU，根据当前无线信道质量所决定的TB Size（传输块大小），切分成合适的大小进行传输。这是一个动态的、逐个传输机会（TTI）决定的物理层适配过程。
RRC层消息分片 (Message Segmentation): 这是一个更上层的机制，且仅在RRC消息本身的大小超过了PDCP层能处理的SDU上限时才触发。它在RRC层将一个完整的、已编码的RRC消息（如RRCReconfiguration）切片，然后将每个切片作为一个独立的RRC消息（DLDedicatedMessageSegment）来发送。它解决的是协议栈内部处理单元的容量限制问题，而非空口传输适配问题。

Q4：UE上报FailureInformation消息后，网络会如何响应？会立即帮UE解决问题吗？

A4：不一定会立即响应或解决问题。FailureInformation主要是一种报告机制，其目的更偏向于网络侧的监控、诊断和长期优化，而非实时的故障恢复。网络收到后，通常会：

记录日志: 将失败事件与UE ID、小区ID、时间等信息关联，存入日志。
性能统计: 聚合大量UE的失败报告，分析某个小区、某个频段或某种用户行为是否与高失败率相关。
触发告警: 如果在短时间内收到大量来自同一区域的失败报告，可能会触发网络运维系统的告警。

对于UE本身，如果失败是暂时的，UE的底层协议（如RLC重传）可能会自行恢复；如果失败持续，最终可能导致更严重的无线链路失败（RLF），从而触发RRC重建流程。

Q5：DLInformationTransfer和DLInformationTransferMRDC有什么关系？

A5：DLInformationTransferMRDC是DLInformationTransfer在MR-DC（Multi-RAT Dual Connectivity，多RAT双连接）场景下的一个特殊变体。

DLInformationTransfer用于在单个RAT（NR）内部传输下行信息。
DLInformationTransferMRDC则专门用于在快速MCG链路恢复期间，通过一个RAT的链路（例如LTE）向下行传输另一个RAT（例如NR）的RRC消息。它的主要目的是在主小区组（MCG）链路失败时，能够快速地通过辅小区组（SCG）链路发送MCG的重配或释放指令，以加速链路恢复过程。可以把它理解为双连接场景下的一个“紧急信道”。

51学通信

探索

深度解析 3GPP TS 38.331：第六章协议数据单元、格式与参数 (Part 2 - 核心下行消息与失败报告)

深度解析 3GPP TS 38.331：第六章协议数据单元、格式与参数 (Part 2 - 核心下行消息与失败报告)

前情回顾与本章主角

1. DedicatedSIBRequest (专用SIB请求)

1.1 消息结构 (ASN.1)

1.2 关键参数解读

1.2.1 `requestedSIB-List`

1.2.2 `requestedPosSIB-List`

2. DLDedicatedMessageSegment (下行专用消息分片)

2.1 消息结构 (ASN.1)

2.2 关键参数解读

3. DLInformationTransfer (下行信息传输)

3.1 消息结构 (ASN.1)

3.2 关键参数解读

4. FailureInformation (失败信息)

4.1 消息结构 (ASN.1)

4.2 关键参数解读

5. 小结

FAQ环节

关系图谱

目录

51学通信

探索

深度解析 3GPP TS 38.331：第六章 协议数据单元、格式与参数 (Part 2 - 核心下行消息与失败报告)

深度解析 3GPP TS 38.331：第六章 协议数据单元、格式与参数 (Part 2 - 核心下行消息与失败报告)

前情回顾与本章主角

1. DedicatedSIBRequest (专用SIB请求)

1.1 消息结构 (ASN.1)

1.2 关键参数解读

1.2.1 requestedSIB-List

1.2.2 requestedPosSIB-List

2. DLDedicatedMessageSegment (下行专用消息分片)

2.1 消息结构 (ASN.1)

2.2 关键参数解读

3. DLInformationTransfer (下行信息传输)

3.1 消息结构 (ASN.1)

3.2 关键参数解读

4. FailureInformation (失败信息)

4.1 消息结构 (ASN.1)

4.2 关键参数解读

5. 小结

FAQ环节

关系图谱

目录

深度解析 3GPP TS 38.331：第六章协议数据单元、格式与参数 (Part 2 - 核心下行消息与失败报告)

深度解析 3GPP TS 38.331：第六章协议数据单元、格式与参数 (Part 2 - 核心下行消息与失败报告)

1.2.1 `requestedSIB-List`

1.2.2 `requestedPosSIB-List`