定义
RRC（Radio Resource Control，无线资源控制）状态描述终端（UE）与基站（eNB/gNB）之间的连接程度，是LTE/5G 移动性管理的核心。LTE定义RRC_IDLE与RRC_CONNECTED两态；5G NR新增RRC_INACTIVE作为轻连接态，在省电与快速恢复之间取得平衡。状态转换影响功耗、连接建立时延、寻呼、切换、重选等行为。
状态详解
- RRC_IDLE：空闲态，无RRC连接，UE进行小区重选、监听寻呼；核心网保留UE上下文，可发起下行寻呼；功耗最低
- RRC_CONNECTED：连接态，有RRC连接，可进行数据传输、切换、测量上报；基站保留UE上下文，可调度资源
- RRC_INACTIVE：5G独有，轻连接态，RAN保留UE上下文；UE可进行重选、监听寻呼，无数据传输时类似IDLE省电；有数据时快速恢复至CONNECTED，无需重新建立PDU会话
状态转换与优化
IDLE→CONNECTED：UE发起RRC连接建立（如NAS附着、业务请求）；CONNECTED→IDLE：RRC释放（如长时间无业务、定时器超时）。5G的RRC_INACTIVE通过RAN-based寻呼与快速恢复，显著降低IoT等小数据业务的时延与信令开销。eDRX、PSM等省电机制与RRC状态协同，优化物联网设备续航。
典型应用场景
RRC状态管理影响所有蜂窝业务：语音通话需保持CONNECTED；物联网设备周期性上报可充分利用IDLE/INACTIVE省电，有数据时快速恢复。达希物联的物联网卡在配置eDRX、PSM时，需结合业务模型与RRC状态转换策略，平衡时延与功耗。
达希物联的物联网设备通过蜂窝网络接入时，其RRC状态转换直接影响设备功耗与平台下发时延。对于周期性上报的传感器，设备多数时间处于IDLE/INACTIVE，可显著省电；对于需实时下发的场景（如远程控制），需考虑寻呼周期与RRC恢复时延。达希物联在为客户选型模组与配置省电参数时，会结合业务模型与RRC状态机制，给出优化建议。
上下文留在基站还是只留在核心网
RRC状态描述的是终端和基站之间还保留多少无线上下文，不是SIM有没有注册。空闲态把无线连接释放掉，基站不再保存调度上下文，终端自己选小区、听寻呼，核心网仍记着它的位置范围。连接态建立了信令无线承载，基站可以调度上下行、要求测量和切换。5G增加的非活跃态把接入层上下文留在基站或锚点，终端可以睡觉和重选，有数据时用较短的恢复过程回到连接态，不必从核心网重新做完整建立。三种状态的耗电、下行时延和信令数量因此不同。
状态由不活动定时器、业务到达和终端请求共同推动。定时器到期，基站释放到空闲或非活跃；上行数据或寻呼响应把终端拉回连接。应用层看到的“在线”常常只是服务器还留着TCP会话，无线侧可能早已空闲。两边的在线不是同一个状态。
非活跃态适合间歇小包
空闲态适合大部分时间不通信、可以忍受寻呼加上随机接入的设备。连接态适合要连续调度或频繁测量的业务，例如正在进行的通话和持续上报。非活跃态适合小包间歇到达、又希望恢复比重建快的5G终端，前提是网络开通了这一状态，终端能力也支持，并且锚点在终端移动后仍然找得到。网络没有开通时，终端请求不会得到该状态，释放后就是空闲。
省电特性要和状态配合。PSM是空闲之后进一步减少甚至停止监听的方式，期间下行基本不可达。eDRX改变的是空闲或非活跃下的监听间隔。在连接态配置这些参数不会让设备进入深睡。需要随时下行的设备应缩短释放定时器的反面——也就是不要让它过早进入听不见寻呼的状态。可结合位置更新核对：空闲时间很长之后，位置如果过期，即使状态机正确，寻呼范围也是错的。
不活动定时器过短造成反复重建
容易出错的是把释放定时器设成一两秒，业务却每几秒来一个小包。终端不断释放、寻呼、随机接入，电量和信令都高于一直保持连接，时延也不稳定。反向的错误是永不释放，几千台设备占着连接态上下文，基站表项耗尽，后来的设备建立失败。另一个错误是用服务器TCP保活每分钟拨一次，足以把终端从空闲打醒，省电配置全部失效，日志里却看不出应用有业务。
5G非活跃态还会被误当成空闲。非活跃仍占用基站上下文，大量终端进入该状态时要看基站容量，不是只看核心网注册数。排查时应在模组侧打印状态变化和原因，对照平台下行时刻。若每次下行前都有完整附着而不是恢复，说明没有进入预期状态，或恢复失败后回到了初始建立。
服务器侧的传输保活若按一分钟一次发送，足以把终端从空闲打回连接，省电定时器永远等不到到期。应把保活周期放得比释放定时器更长，或改成有业务才发送。非活跃态仍占用基站侧上下文，大量终端同时进入时要看基站表项，而不是只看核心网注册成功的数量。释放原因、恢复失败原因和再次附着要分成三列记录，否则无法区分是定时器过短还是恢复过程本身失败。