51学通信

深度解析 3GPP TS 38.300：7.6-7.10 RRC 连接态下的精细化管理

20分钟阅读

好的，在理解了RRC层如何进行“入场管理”之后，我们继续深入探讨RRC这位“总导演”在UE成功入场（建立连接）后，是如何通过一系列精巧的信令，来指挥UE高效地利用网络资源、节省功耗，并保证信令的有序传递。

深度解析 3GPP TS 38.300：7.6-7.10 RRC 连接态下的精细化管理

本文技术原理深度参考了3GPP TS 38.300 V18.5.0 (2025-03) Release 18规范中，关于“7.6 Transport of NAS Messages”、“7.7 Carrier Aggregation”、“7.8 Bandwidth Adaptation”、“7.9 UE Assistance Information”以及“7.10 Segmentation of RRC messages”的核心章节，旨在为读者全面揭示RRC在连接态下进行NAS消息承载、多载波管理、带宽自适应、UE辅助信息交互以及大信令分段的核心机制。

前言：从“入场”到“入座观影”的全流程服务

在上一章，我们探讨了RRC如何像体育馆的“安检”和“票务”一样，对海量UE进行接入控制和能力核查。现在，我们的主角小明已经成功“入场”，进入了RRC_CONNECTED状态。但这仅仅是开始，为了让小明能够舒适、流畅地“观看演出”（享受5G业务），RRC这位“总导演”还需要提供一系列“入座”后的精细化服务。

这套服务就像一场精心编排的戏剧，涉及到多个环节：

  1. 贵宾信件投递（NAS消息传输）：如何将核心网（AMF）发来的“密信”安全、可靠地送达小明？

  2. 座位升级与合并（载波聚合）：当小明需要观看超高清视频时，如何为他动态地增加“座位”（带宽）？

  3. 节能模式（带宽自适应）：在“中场休息”时，如何让他的“座位”区域（射频带宽）暂时“熄灯”，以节省能源？

  4. 观众反馈（UE辅助信息）：如何倾听小明的“呼声”（例如，手机过热、想提前离场），并做出响应？

  5. 超长节目单分发（RRC消息分段）：当“节目单”（RRC配置消息）过长时，如何分册派发，确保他能完整收到？

今天，我们将深入RRC连接态管理的后台，逐一揭秘这些确保用户极致体验的“导演秘辛”。

1. “机要信使”：NAS消息的可靠传输 (7.6)

在RRC连接建立后，UE和核心网的AMF之间，仍然需要持续地交换**NAS（非接入层）**信令，例如进行用户鉴权、会话管理等。RRC层此时扮演的角色，就是一个绝对可靠的“机要信使”。

NR provides reliable in-sequence delivery of NAS messages over SRBs in RRC… In RRC, NAS messages are sent in transparent containers.

  • 可靠有序的投递：RRC通过信令无线承载（SRB）来传输NAS消息。我们已经知道，SRB被配置了最可靠的RLC AM模式和最高的MAC优先级，确保了NAS消息的可靠和有序交付。

  • “透明信封”封装：对于RRC层来说，NAS消息的内容是“不透明”的。它就像一个被封好的信封，RRC只负责将这个信封（NAS-PDU）放入一个更大的RRC快递包裹（如DLInformationTransfer或ULInformationTransfer消息）中，进行投递，而不会拆开或解读其中的内容。

Piggybacking of NAS messages can occur in the following scenarios:

  • At bearer establishment/modification/release in the DL;
  • For transferring the initial NAS message during connection setup and connection resume in the UL.

  • “捎带”投递（Piggybacking）：为了提升信令效率，NAS消息常常被“捎带”在其他的RRC消息中。

    • 下行捎带：当网络需要为UE建立一个新的数据承载（DRB）时，AMF发给SMF的NAS消息（如PDU SESSION MODIFICATION COMMAND），会由AMF先发给gNB，gNB再将其“捎带”在下发给UE的RRCReconfiguration消息中，一并送达。

    • 上行捎带：UE在连接建立过程中的第一条上行NAS消息（如Registration Request），就是被“捎带”在RRCSetupComplete消息中发往gNB的。

2. “座位动态升舱”：载波聚合管理 (7.7)

当小明开始播放4K视频，单个载波的带宽可能无法满足需求。此时，RRC“总导演”就会为他进行“座位升舱”——激活载波聚合（CA）。

When CA is configured, the UE only has one RRC connection with the network. At RRC connection establishment/re-establishment/handover, one serving cell provides the NAS mobility information, and (…) provides the security input. This cell is referred to as the Primary Cell (PCell).

RRC对CA的管理，遵循主次分明的原则：

  • 唯一的RRC连接：无论聚合了多少个载波，UE始终只维护一个RRC连接，这个连接锚定在**主小区（PCell）**上。PCell负责所有核心的信令交互和安全管理。

  • 辅小区的动态增删：

    The reconfiguration, addition and removal of SCells can be performed by RRC.

    gNB的RRC层会根据业务负载、UE能力和测量报告，通过发送RRCReconfiguration消息，来动态地为UE添加、修改或移除辅小区（SCell）。

When adding a new SCell, dedicated RRC signalling is used for sending all required system information of the SCell i.e. while in connected mode, UEs need not acquire broadcast system information directly from the SCells.

  • SCell系统信息的专用递送：这是一个提升CA效率的关键点。当为UE添加一个SCell时，UE不需要再去像初始接入一样，费力地去监听和解码那个SCell的广播系统信息（MIB/SIB）。gNB会直接将那个SCell的必要系统信息，打包在专用的RRCReconfiguration消息中，一并告诉UE。这大大缩短了SCell的激活时间。

3. “智能节能”：带宽自适应管理 (7.8)

即便配置了CA，UE也不需要时刻在所有载波的全部带宽上工作。RRC通过**带宽自适应（Bandwidth Adaptation, BA）**机制，为UE实现了更精细的节能管理。

To enable BA on the SpCell, the gNB configures the UE with UL and DL BWP(s). … Switching between configured BWPs happens by means of RRC signalling, DCI, inactivity timer or upon initiation of random access.

RRC为UE配置一个或多个带宽部分（BWP），并在它们之间进行动态切换：

  • RRC配置：RRC层负责为UE配置一个BWP列表，并指定其中一个是“默认BWP（default BWP）”。默认BWP通常是一个窄带宽的、用于维持基本连接和监听控制信令的BWP。

  • 动态切换：激活哪个BWP，可以通过多种方式触发：

    1. DCI：这是最快的方式。gNB可以在DCI中用一个几比特的字段，直接命令UE切换到指定的BWP。

    2. BWP非活动定时器 (bwp-InactivityTimer)：RRC可以为每个非默认BWP配置一个非活动定时器。当UE在一个宽带BWP上收发完数据后，该定时器启动。如果定时器超时，而没有新的数据调度，UE就会自动回退到默认的窄带BWP上，以节省功耗。

    3. RRC信令：RRC也可以通过RRCReconfiguration消息，显式地命令UE切换BWP。

通过BWP的动态切换，UE的射频和基带可以像“变速箱”一样，在“节能挡”（窄带BWP）和“性能挡”（宽带BWP）之间灵活切换，实现了性能与功耗的完美平衡。

4. “倾听观众呼声”：UE辅助信息 (7.9)

一个好的“导演”，不仅要会指挥，还要善于倾听“演员”的反馈。RRC通过**UE辅助信息（UEAssistanceInformation）**这条上行通道，来倾听UE的“呼声”。

When configured to do so, the UE can signal the network through UEAssistanceInformation:

UE可以通过这条消息，向网络表达一系列“偏好”或报告自己的“状态”：

  • DRX参数偏好：UE可以告诉网络，“我希望我的DRX周期更长一些/更短一些”，以平衡时延和功耗。

  • 过热报告：

    • If it is experiencing internal overheating;

    这是非常重要的功能。当手机因为高负载运行（如玩大型游戏、烈日下导航）而过热时，UE会主动上报过热信息，并建议网络降低其性能配置，例如“减少SCell数量”、“降低MIMO层数”等，以避免设备损坏。

  • “提前离场”意愿：

    • If it expects not to send or receive any more data in the near future… it can provide its preference to transition out of RRC_CONNECTED…

    当UE预测自己的业务已经结束时（例如，一个大文件下载完成），它可以提前告知网络“我准备休息了”，并建议网络将其释放到IDLE或INACTIVE状态，从而更及时地进入节能模式。

  • IDC（设备内共存）问题：当手机的5G模块受到其内部其他模块（如Wi-Fi、蓝牙、GPS）的干扰时，UE可以通过这条消息上报受干扰的频点信息，请求网络进行规避调度。

UEAssistanceInformation机制的引入，使得UE不再是一个被动的指令执行者，而是一个能够主动与网络协商、共同优化网络体验的智能体。

5. “鸿篇巨著”的派发：RRC消息分段 (7.10)

RRC消息，特别是RRCReconfiguration，有时会变得非常庞大，比如在首次配置DC或复杂CA时，其内容可能远超底层PDCP SDU的最大尺寸。这时，就需要对这条“鸿篇巨著”进行分册派发。

An RRC message may be segmented in case the size of the encoded RRC message PDU exceeds the maximum PDCP SDU size. Segmentation is performed in the RRC layer using a separate RRC PDU to carry each segment.

RRC分段机制在RRC层本身完成：

  1. 分段：发送端RRC层将一条大的RRC消息，分割成多个独立的、带有分段信息的RRC PDU。

  2. 独立传输：每个分段后的RRC PDU都作为一个独立的信令，通过SRB进行传输。

  3. 重组：接收端RRC层收集所有的分段PDU，并根据其中的分段信息，将它们重组为原始的RRC消息，然后再进行解析和执行。

All segments of an RRC message are transmitted before sending another RRC message.

为了保证信令处理的原子性，规范要求一条RRC消息的所有分段，必须在发送下一条新的RRC消息之前，全部发送完毕。

总结：精雕细琢的连接态艺术

通过对7.6至7.10节的深入学习，我们看到了RRC在UE进入CONNECTED状态后，是如何通过一系列精细化的管理手段，来持续优化用户体验和网络效率的：

  1. 可靠的信使 (NAS传输)：通过SRB的可靠通道和“捎带”机制，高效、安全地完成了核心网信令的传递。

  2. 动态的资源扩展 (CA管理)：以PCell为锚点，通过专用的RRC信令动态增删SCell，实现了带宽的弹性伸缩。

  3. 智能的功耗管理 (BA管理)：通过DCI、定时器等多种方式，实现了BWP的快速切换，在性能和功耗之间找到了最佳平衡点。

  4. 主动的交互 (UE辅助信息)：通过UEAssistanceInformation，建立了一条从UE到网络的反馈通道，使得网络决策能更好地匹配UE的实时状态和偏好。

  5. 健壮的信令传输 (RRC分段)：通过在RRC层内置的分段机制，解决了大信令传输的难题，保证了复杂场景配置的可靠性。

RRC连接态下的这些管理艺术，共同构筑了5G卓越用户体验的基石。在下一篇文章中，我们将把目光转向网络中的各种身份标识，看看在5G这个庞大的世界里，UE和网络节点是如何拥有自己独一无二的“身份证”的。

FAQ

Q1：为什么添加SCell时，UE不需要读取广播系统信息？这样做有什么好处？

A1：因为此时UE处于RRC_CONNECTED状态，与gNB之间已经建立了一条安全、可靠的专用信令通道（SRB）。gNB可以直接将SCell的系统信息（通常称为scell-common）打包在RRCReconfiguration消息中，“点对点”地发送给UE。好处是速度快、效率高。UE无需花费时间去盲目地监听和解码一个可能承载着大量与自己无关信息的广播信道，从而可以更快地完成SCell的配置和激活，尽快地利用上SCell的带宽资源。

Q2：BWP（带宽部分）和CC（成员载波）是什么关系？

A2：它们是载波内和载波间的带宽管理概念。CC是载波聚合（CA）的基本单元，指的是一个独立的载波频段。BWP则是在一个CC内部定义的、UE实际工作的带宽子集。关系可以这样理解：一个UE可以被配置多个CC（CA），而在每一个CC上，又可以被配置多个BWP（BA）。CA技术通过聚合多个CC来扩展总带宽，而BA技术则通过在每个CC内部动态切换BWP来节省功耗。

Q3：如果我的手机发热很严重，它真的会主动告诉网络吗？网络会如何响应？

A3：是的，支持R16及以后版本的UE，如果具备过热检测能力，它真的会通过UEAssistanceInformation消息主动向网络上报过热事件。它可能会建议网络采取“降温”措施，比如：减少CA的SCell数量、降低MIMO的传输层数、或者增大DRX周期以增加休眠时间。网络（gNB）收到这个请求后，并不保证一定会满足，但它会根据自己的调度策略和网络负载情况，尽可能地采纳UE的建议。例如，它可能会通过RRCReconfiguration消息释放掉一些SCell，或者在调度时，为该UE选择更低阶的MCS和更少的MIMO层数。这是一种UE与网络之间的协同温控机制。

Q4：NAS消息既然是UE和AMF之间的“私信”，为什么需要gNB来中转，而不是直接发给AMF？

A4：因为在移动通信网络中，UE的任何信令都必须先通过无线接入网（gNB）才能到达核心网。gNB是UE与核心网之间的唯一物理连接点和接入网关。UE并没有一个可以直接与远在核心网的AMF进行IP通信的“直达通道”。NAS信令的传输路径是：UE --(Uu接口, SRB)--> gNB --(NG-C接口, NGAP)--> AMF。gNB在这个过程中扮演了“透明转发”的角色，它为NAS信令提供了一个可靠的、安全的底层传输服务，但并不解析其内容。

Q5：RRC消息分段和TCP/IP的分片有什么区别？

A5：它们发生在协议栈的不同层次，目的和机制也不同。TCP/IP分片发生在IP层或TCP层，是为了将一个大的上层数据包适配到下层链路（如以太网）的最大传输单元（MTU）。这是一个通用的网络层功能。而RRC消息分段发生在RRC层本身，是应用层（这里指RRC）自己实现的分段机制。它专门为了解决单个RRC信令（如一个巨大的配置消息）超过了其下一层——PDCP层的SDU最大尺寸的问题。RRC自己将一条大消息切分成多条带分段标识的小RRC消息，每一条小消息再独立地走完PDCP/RLC/MAC/PHY的完整流程。这种在应用层自己解决分段问题的方式，可以避免修改底层协议，并且能更好地控制信令的重组和处理逻辑。

关系图谱