4. UE状态与迁移：IDLE态、CONNECTED态、PSM态、eDRX态的定义与状态迁移条件
各位好，这一章我们来聊聊NB-IoT终端的状态机。说实话，很多刚入行的朋友容易把状态迁移搞混，尤其是PSM和eDRX这两个省电模式，经常有人问我：“它们到底有啥区别？”
嗯，咱们今天就把这四个状态彻底讲清楚。我习惯把UE的状态比作一个人的一天——有工作、有休息、有深度睡眠、还有打盹儿。你想想看，是不是挺形象的？
4.1 四大状态定义
NB-IoT的UE（终端）有四个核心状态，分别是：IDLE态、CONNECTED态、PSM态和eDRX态。每个状态都有它存在的意义，说白了就是为了在功耗和响应速度之间找个平衡点。
| 状态 | 英文全称 | 核心特征 | 典型功耗 |
|---|---|---|---|
| IDLE态 | Idle State | 可寻呼、可移动、可发起业务 | ~3mA |
| CONNECTED态 | Connected State | 数据传输中、占用无线资源 | ~50-200mA |
| PSM态 | Power Saving Mode | 深度休眠、不可寻呼 | ~3-5μA |
| eDRX态 | Extended Discontinuous Reception | 扩展不连续接收、可寻呼但周期长 | ~0.5-2mA |
我个人习惯把这张表贴在工位上，每次排查功耗问题时，先看一眼UE当前在哪个状态，问题就解决了一半。
4.2 状态迁移条件详解
状态迁移不是随便跳的，它有一套严格的触发条件。我画了个迁移图在脑子里，咱们一步步拆解。
4.2.1 IDLE态 → CONNECTED态
触发条件很简单：UE有上行数据要发，或者网络侧有下行数据要收。
- 上行触发：UE主动发起RRC连接请求（比如传感器上报数据）
- 下行触发：网络侧寻呼UE，UE响应后建立连接
关键点：从IDLE到CONNECTED，UE需要完成随机接入过程（RACH）。我在项目中遇到过，有些模块在弱信号下反复重试RACH，导致功耗飙升。嗯，这里要注意，RACH失败次数多了，UE会退避，不是一直死磕。
4.2.2 CONNECTED态 → IDLE态
数据传完了，网络侧会释放RRC连接。触发条件包括：
- 数据不活动定时器超时（通常配置为10-20秒）
- 网络侧主动释放（比如核心网发RRC Release）
- 无线链路失败（RLF）后回退
说白了，就是“没事干了，别占着茅坑不拉屎”。
4.2.3 CONNECTED态 → PSM态
这个迁移有点特殊。UE在CONNECTED态结束后，会先进入IDLE态，然后根据网络配置的TAU周期和Active Time来决定是否进入PSM。
我的经验：Active Time这个参数很关键。我曾经帮一个客户排查功耗问题，发现他们的UE每隔几分钟就唤醒一次，就是因为Active Time设得太短，UE还没来得及进入PSM就被唤醒了。建议Active Time设置成5-10秒，给UE一个缓冲窗口。
PSM态的进入条件：
- UE在IDLE态下，TAU定时器未超时
- UE没有待发送的数据
- 网络侧在Attach Accept或TAU Accept中携带了PSM参数
4.2.4 IDLE态 → eDRX态
eDRX是IDLE态的一种特殊子状态。UE在IDLE态下，如果网络支持eDRX且UE也支持，就会协商进入eDRX模式。
触发条件：
- UE在Attach Request或TAU Request中携带eDRX能力
- 网络侧在响应中确认eDRX参数（寻呼周期、超帧长度等）
避坑指南：我曾经遇到过，有些运营商网络不支持eDRX，但UE硬要协商，结果网络侧直接忽略，UE就退回到普通DRX模式。所以，别以为配置了eDRX就一定能用，先确认网络侧支持不支持。
4.2.5 PSM态 → IDLE态
PSM态的唤醒条件有两个：
- TAU周期超时：UE必须定期醒来做TAU，否则网络侧会认为UE失联
- 有上行数据要发：比如传感器采集到了新数据
注意，PSM态的UE是不可寻呼的。你想想看，如果服务器想下发指令，UE却在深度睡眠，那只能等它自己醒来。这就是为什么很多NB-IoT应用采用“上行触发+下行缓存”的模式。
4.3 状态迁移完整流程图
我习惯用代码来模拟状态机，这样更直观。下面是一个简化的状态迁移逻辑：
// 伪代码：NB-IoT UE状态迁移
enum UEState {
IDLE,
CONNECTED,
PSM,
eDRX
}
void stateMachine(Event event) {
switch (currentState) {
case IDLE:
if (event == DATA_TO_SEND || event == PAGING_RECEIVED) {
// 发起RRC连接
currentState = CONNECTED;
} else if (event == eDRX_NEGOTIATED) {
currentState = eDRX;
}
break;
case CONNECTED:
if (event == DATA_COMPLETE || event == INACTIVITY_TIMEOUT) {
// 进入IDLE，等待Active Time
startActiveTimer();
currentState = IDLE;
}
break;
case PSM:
if (event == TAU_TIMER_EXPIRED || event == DATA_TO_SEND) {
// 唤醒，发起TAU或数据发送
currentState = IDLE;
}
break;
case eDRX:
if (event == DATA_TO_SEND || event == PAGING_RECEIVED) {
// 退出eDRX，进入CONNECTED
currentState = CONNECTED;
} else if (event == eDRX_TIMEOUT) {
// 回到普通IDLE
currentState = IDLE;
}
break;
}
}
4.4 实际项目中的状态迁移问题
我记得有一次，一个做智能水表的客户反馈，他们的设备电池只能用3个月，而设计目标是5年。我一看日志就发现问题了——UE几乎一直处于CONNECTED态，根本没进入PSM。
排查下来，原因是数据上报频率太高（每5分钟一次），而且每次上报后网络侧释放连接太慢。我建议他们把上报间隔改成1小时，同时调整了Inactivity Timer从20秒降到10秒。结果电池寿命直接提升到了4年半。
所以，状态迁移的优化，说白了就是三个字：控节奏。
4.5 各状态下的关键参数配置建议
| 参数 | 影响的状态 | 推荐值 | 说明 |
|---|---|---|---|
| Active Time | IDLE → PSM | 5-10秒 | 给UE足够时间进入PSM |
| TAU周期 | PSM → IDLE | 24小时（典型） | 根据业务需求调整，越长越省电 |
| eDRX周期 | eDRX | 20.48秒（NB-IoT典型） | 平衡寻呼延迟和功耗 |
| Inactivity Timer | CONNECTED → IDLE | 10-20秒 | 数据传完后尽快释放资源 |
小技巧：如果你不确定参数怎么配，可以先从运营商默认值开始。我习惯用抓包工具（比如Wireshark）看Attach Accept消息里的参数，网络侧配了什么，UE就跟着走。别自己瞎改，容易出问题。
好了，这一章的内容就到这里。状态迁移是NB-IoT功耗优化的核心，你只要把IDLE、CONNECTED、PSM、eDRX这四个状态搞明白，再配合参数调优，基本上就能解决80%的功耗问题。下一章咱们聊聊具体的注册流程，到时候会用到这些状态知识。