3、3GPP R13 PSM机制详解
PSM，全称Power Saving Mode，是3GPP R13引入的省电大招。说白了，就是让UE在空闲态能睡得更久。我刚开始接触这个特性时，第一反应是：这不就是深度休眠吗？后来踩了几个坑才发现，没那么简单。
3.1 PSM的引入背景
在R13之前，LTE的省电机制其实挺尴尬的。UE在空闲态虽然能睡，但每隔一段时间就得醒过来做TAU（Tracking Area Update）。这个周期性TAU，就像闹钟一样，不管你困不困，到点就得响。
为什么会这样？因为网络需要知道你在哪。你想想看，如果UE一直睡，网络侧就不知道你的位置，有来电时寻呼不到你。所以3GPP设计了一个折中：让UE定期醒来报个到。
但问题来了——很多物联网应用根本不需要实时可达。比如水表、电表、智能停车位，它们一天上报一次数据就够了。对于这些设备，频繁的TAU完全是浪费电。
我记得在R12时代，有个客户做智能水表，电池容量只有2000mAh，要求续航10年。我们用传统空闲态省电方案算了一下，光TAU就吃掉了一半电量。这显然不行。
于是，3GPP在R13引入了PSM。它的核心思想是：允许UE在完成数据传输后，进入一个超长休眠状态，期间完全不可达。网络侧知道你在睡，不会寻呼你，也不会要求你做TAU。
PSM的核心价值：将UE的休眠时间从分钟级延长到小时级甚至天级，同时消除不必要的TAU开销。
3.2 TAU周期与Active Timer
PSM涉及两个关键定时器，搞懂它们，你就掌握了PSM的命门。
| 定时器 | 名称 | 取值范围 | 作用 |
|---|---|---|---|
| T3412 | 周期性TAU定时器 | 0~413天 | 控制UE在空闲态时，多久做一次TAU |
| T3324 | Active Timer | 0~186分钟 | 控制UE进入PSM前的等待时间 |
周期性TAU定时器（T3412）
这个定时器在R13之前就有了。UE在空闲态时，每T3412秒到期，就要发起一次TAU。R13之后，T3412的最大值从原来的约310小时扩展到了413天。嗯，你没看错，413天。这意味着UE可以一年半才做一次TAU。
我在项目中遇到过一个问题：运营商核心网侧配置的T3412最大值只有357小时（约15天）。UE虽然请求了413天，但网络侧会拒绝，最终协商下来只有15天。所以，PSM的省电效果，不光看UE，还得看网络侧是否支持。
Active Timer（T3324）
这个定时器是R13新增的。UE在完成数据传输后，会启动Active Timer。在这段时间内，UE保持空闲态，可被寻呼。Active Timer超时后，UE才进入PSM。
为什么要设计这个Active Timer？因为有些应用场景，UE发完数据后，服务器可能还有后续指令要下发。比如智能门锁，用户开锁后，服务器可能还要下发一个确认消息。如果UE立刻进入PSM，这个消息就收不到了。
我个人习惯把Active Timer设成10~30秒。太短了，服务器来不及下发指令；太长了，又浪费电。具体值取决于你的应用场景。
避坑指南：我曾经把Active Timer设成0秒，结果UE发完数据立刻进入PSM。服务器后续下发的配置更新指令全部丢失，设备整整离线了12小时。从那以后，我至少留10秒的窗口期。
3.3 PSM状态机转换
PSM的状态机其实不复杂，但有几个关键点容易搞混。我画了一张图，帮你理清整个流程。
整个状态机转换，我总结为四个关键步骤：
- 数据发送完成：UE在RRC Connected态完成数据收发后，释放连接进入RRC Idle态。
- Active Timer倒计时：UE在Idle态启动Active Timer（T3324）。这段时间内，UE可被寻呼，网络侧可以下发数据。
- 进入PSM：Active Timer超时后，UE进入PSM。射频关闭，UE完全不可达。此时UE只维护一个定时器：T3412（周期性TAU定时器）。
- 退出PSM：T3412到期，或者UE有上行数据要发，UE退出PSM，发起TAU或直接建立RRC连接。
注意：PSM状态下，UE虽然省电，但有一个代价——下行数据无法实时到达。如果你的应用需要服务器随时能唤醒设备，PSM就不合适。这种情况下，应该考虑eDRX（扩展不连续接收），我们下一章会讲。
3.4 PSM的协商流程
PSM不是UE单方面决定的，需要UE和网络侧协商。流程如下：
- 步骤1：UE在Attach Request或TAU Request中，携带PSM能力指示和请求的Active Timer值（T3324）。
- 步骤2：MME收到请求后，根据网络策略和UE订阅信息，决定是否接受PSM。如果接受，MME在Attach Accept或TAU Accept中返回协商后的Active Timer值。
- 步骤3：UE收到Accept后，按照协商值启动Active Timer。如果MME拒绝PSM（不返回T3324），UE就不能进入PSM。
我在实际调试中遇到过一种情况：UE发了PSM请求，MME也返回了T3324，但UE就是不进入PSM。查了半天，发现是UE的NAS层实现有bug——Active Timer启动后，被一个高优先级定时器打断了。嗯，这种问题最头疼，只能打补丁。
调试技巧：用抓包工具看NAS信令，重点关注Attach Request中的“T3324 value”和Attach Accept中的“T3324 value”。如果Accept里没有T3324，说明网络侧不支持PSM，或者你的签约数据没开通PSM权限。
3.5 PSM的功耗收益
PSM的省电效果有多明显？我拿一个实际项目的数据给你看：
| 场景 | 无PSM | 有PSM（T3324=20s, T3412=24h） |
|---|---|---|
| 每日TAU次数 | 24次（每小时1次） | 1次（每天1次） |
| 每日寻呼监听时间 | 约144分钟 | 约20秒（仅Active Timer期间） |
| 日均功耗 | 约12mAh | 约0.8mAh |
| 2000mAh电池续航 | 约166天 | 约6.8年 |
看到没？PSM把续航从半年提升到了接近7年。这就是为什么物联网设备普遍采用PSM的原因。
不过，这里有个前提——你的设备每天只发一次数据。如果数据上报频率高，PSM的优势就不明显了。比如每5分钟发一次数据，UE根本没机会进入PSM，Active Timer刚启动，新数据又来了。
所以，PSM最适合的是那些低频率、非实时、上行为主的物联网应用。选型时一定要想清楚你的业务模型。