2、RRC状态机精讲：从RRC_IDLE到RRC_CONNECTED的完整信令流程，以及状态迁移的功耗代价

各位做功耗优化的同行，咱们今天来啃一块硬骨头——RRC状态机。说实话，我刚入行那会儿，觉得这东西就是个协议栈里的标准流程，背下来就完事了。直到我接手第一个物联网模块项目，发现设备待机电流死活降不下来，才意识到：不懂RRC状态迁移的功耗代价，你做的功耗优化全是空中楼阁。

RRC状态机，说白了就是UE和网络之间的一种“亲密度”管理机制。你想想看，手机不可能一直跟基站保持热线联系，那样电池撑不过两小时。但也不能完全失联，否则电话打不进来。所以3GPP设计了三个核心状态：RRC_IDLE、RRC_CONNECTED，以及中间过渡态。嗯，这里要注意，LTE里其实还有个RRC_INACTIVE，但那是R15才引入的，咱们放到后面章节细讲。

2.1 三大状态的定义与功耗画像

先给个全景图。我习惯把RRC状态机比作一个“三档变速器”：

• RRC_IDLE：低功耗待机档。UE只监听寻呼信道，没有专用无线资源。DRX周期可以配置到2.56秒，电流通常在1~3mA级别。
• RRC_CONNECTED：全速运行档。UE有专用C-RNTI，可以随时收发数据。但代价是射频收发器持续工作，电流轻松飙到50~200mA。
• 中间过渡态：严格来说，从IDLE到CONNECTED不是瞬间完成的，中间要经过随机接入、RRC连接建立、安全激活等子阶段。每个子阶段的功耗都不一样。

我在项目中遇到过最典型的坑：某模块上报传感器数据，每次上报都从IDLE开始走完整信令流程。数据量只有几十字节，但信令开销占了总功耗的90%以上。后来改成保持短时间CONNECTED态，用DRX收尾，功耗直接砍掉三分之二。

状态	典型电流	射频状态	可收发数据	迁移触发条件
RRC_IDLE	1~3 mA	关闭/DRX监听	否（仅接收寻呼）	无活动定时器超时
RRC_CONNECTED	50~200 mA	持续收发	是	RRC连接建立完成
过渡态（随机接入）	100~300 mA（峰值）	突发收发	否	上行数据到达/寻呼响应

2.2 完整信令流程：从IDLE到CONNECTED

好，咱们来走一遍完整的信令流程。这个过程我拆成五个阶段，每个阶段都有明确的信令消息和功耗特征。

为什么会这么复杂？因为网络需要确认三件事：你是谁？你在哪？你是否有权限接入？

1. 寻呼/上行触发：UE在IDLE态收到寻呼消息（下行），或者应用层有数据要发（上行），触发状态迁移。
2. 随机接入（Random Access）：UE发送Preamble，eNB回复Random Access Response。这一步建立上行同步。
3. RRC连接建立：UE发送RRC Connection Request，eNB回复RRC Connection Setup，UE再回复RRC Connection Setup Complete。这一步建立SRB1。
4. 安全激活：eNB下发Security Mode Command，UE回复Security Mode Complete。这一步激活AS层加密和完整性保护。
5. RRC重配置：eNB下发RRC Connection Reconfiguration（携带DRB配置），UE回复RRC Connection Reconfiguration Complete。这一步建立数据无线承载。

我记得第一次用抓包工具看完整流程时，发现从Preamble到RRC重配置完成，最快也要50~80毫秒。这期间UE的射频一直处于高功率状态，平均电流在150mA以上。算下来，一次完整迁移的功耗代价大约是：

150mA × 3.8V × 0.08s ≈ 45.6 mJ

而IDLE态待机一秒的功耗只有：2mA × 3.8V × 1s ≈ 7.6 mJ。也就是说，一次状态迁移的能耗相当于IDLE态待机6秒钟。如果你的设备每小时上报一次数据，光状态迁移就吃掉了一半的功耗预算。

2.3 状态迁移的功耗代价量化

咱们把每个阶段的功耗拆开来看。我习惯用一张表来记录实测数据：

阶段	持续时间	平均电流	能耗占比	优化空间
寻呼监听	1~2 ms	30~50 mA	<1%	调整DRX周期
随机接入（Preamble+RAR）	10~30 ms	150~250 mA	15~25%	优化Preamble功率爬升
RRC连接建立	15~25 ms	100~180 mA	20~30%	减少信令消息大小
安全激活	10~15 ms	100~150 mA	10~15%	硬件加速加密
RRC重配置	15~20 ms	100~150 mA	15~20%	预配置DRB参数

你看，随机接入和RRC连接建立这两个阶段，占了总能耗的一半以上。原因很简单：这两个阶段UE需要发送上行信号，而功放的效率在低功率输出时是很差的。说白了，你发一个Preamble的功耗，可能比收三个下行消息还高。

2.4 状态迁移的完整流程图

下面这张图是我自己整理的RRC状态迁移流程，包含了信令交互和功耗变化曲线。你仔细看，每个阶段的电流波形都不一样：

2.5 优化策略：从信令层面压榨功耗

知道了流程和代价，接下来就是怎么优化。我总结了三条实战策略：

• 策略一：减少状态迁移次数。这是最直接的方法。把多次小数据包合并成一次大数据包发送，或者延长CONNECTED态的非活动定时器，避免频繁进出IDLE。我有个项目把上报周期从1分钟改成5分钟，状态迁移次数减少了80%，整机续航从3天延长到12天。
• 策略二：优化随机接入过程。在弱信号环境下，Preamble的初始发射功率可以适当提高，减少功率爬升次数。但要注意，功率提高会增加瞬时电流，需要权衡。我一般建议在RSRP低于-120dBm时，把初始Preamble功率提高3~6dB。
• 策略三：利用RRC_INACTIVE（R15+）。如果你的网络支持R15，RRC_INACTIVE是一个很好的中间状态。它保留了UE的上下文，从INACTIVE到CONNECTED只需要4步信令（Resume流程），比完整流程少了一半。功耗介于IDLE和CONNECTED之间。